System for controlling the distribution and use of digital works using digital tickets

ABSTRACT

A method, system and software for controlling the number of times that a usage right associated with a digital work can be exercised, including creating a digital work; determining a usage right for the digital work, the usage right specifying a digital ticket, the digital ticket indicating a number of times the usage right may be exercised; requesting access to the digital work including an identification of the usage right; determining the validity of the usage right based on a number of times the digital ticket has been used; granting or denying access to the digital work based on the result of the determining step; and updating the digital ticket if access to the digital work is granted.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a divisional of co-pending U.S. patent applicationSer. No. 11/135,352 of STEFIK, et al., filed on May 24, 2005, entitled“METHOD AND APPARATUS FOR EXECUTING CODE IN ACCORDANCE WITH USAGERIGHTS,” and is related to U.S. patent application Ser. No. 09/777,966of STEFIK, et al., filed on Feb. 7, 2001, entitled “SYSTEM FORCONTROLLING THE DISTRIBUTION AND USE OF DIGITAL WORKS USING DIGITALTICKETS,” now U.S. Pat. No. 6,944,600, which is a divisional of U.S.patent application Ser. No. 08/967,084, filed on Nov. 10, 1997, now U.S.Pat. No. 6,236,971, which is a continuation of U.S. patent applicationSer. No. 08/344,760, filed on Nov. 23, 1994, now abandoned, the entiredisclosures of all of which are hereby incorporated by reference herein.

FIELD OF THE INVENTION

The present invention relates to the field of distribution and usagerights enforcement for digitally encoded works.

BACKGROUND OF THE INVENTION

A fundamental issue facing the publishing and information industries asthey consider electronic publishing is how to prevent the unauthorizedand unaccounted distribution or usage of electronically publishedmaterials. Electronically published materials are typically distributedin a digital form and recreated on a computer based system having thecapability to recreate the materials. Audio and video recordings,software, books and multimedia works are all being electronicallypublished. Companies in these industries receive royalties for eachaccounted for delivery of the materials, e.g. the sale of an audio CD ata retail outlet. Any unaccounted distribution of a work results in anunpaid royalty (e.g. copying the audio recording CD to another digitalmedium.)

The ease in which electronically published works can be “perfectly”reproduced and distributed is a major concern. The transmission ofdigital works over networks is commonplace. One such widely used networkis the Internet. The Internet is a widespread network facility by whichcomputer users in many universities, corporations and governmententities communicate and trade ideas and information. Computer bulletinboards found on the Internet and commercial networks such as CompuServand Prodigy allow for the posting and retrieving of digital information.Information services such as Dialog and LEXIS/NEXIS provide databases ofcurrent information on a wide variety of topics. Another factor whichwill exacerbate the situation is the development and expansion of theNational Information Infrastructure (the NII). It is anticipated that,as the NII grows, the transmission of digital works over networks willincrease many times over. It would be desirable to utilize the NII fordistribution of digital works without the fear of widespreadunauthorized copying.

The most straightforward way to curb unaccounted distribution is toprevent unauthorized copying and transmission. For existing materialsthat are distributed in digital form, various safeguards are used. Inthe case of software, copy protection schemes which limit the number ofcopies that can be made or which corrupt the output when copying isdetected have been employed. Another scheme causes software to becomedisabled after a predetermined period of time has lapsed. A techniqueused for workstation based software is to require that a specialhardware device must be present on the workstation in order for thesoftware to run, e.g., see U.S. Pat. No. 4,932,054 entitled “Method andApparatus for Protecting Computer Software Utilizing Coded FilterNetwork in Conjunction with an Active Coded Hardware Device.” Suchdevices are provided with the software and are commonly referred to asdongles.

Yet another scheme is to distribute software, but which requires a “key”to enable its use. This is employed in distribution schemes where“demos” of the software are provided on a medium along with the entireproduct. The demos can be freely used, but in order to use the actualproduct, the key must be purchased. These schemes do not hinder copyingof the software once the key is initially purchased.

A system for ensuring that licenses are in place for using licensedproducts is described in PCT Publication WO 93/01550 to Griswoldentitled “License Management System and Method.” The licensed productmay be any electronically published work but is most effective for usewith works that are used for extended periods of time such as softwareprograms. Griswold requires that the licensed product contain softwareto invoke a license check monitor at predetermined time intervals. Thelicense check monitor generates request datagrams which identify thelicensee. The request datagrams are sent to a license control systemover an appropriate communication facility. The license control systemthen checks the datagram to determine if the datagram is from a validlicensee. The license control system then sends a reply datagram to thelicense check monitor indicating denial or approval of usage. Thelicense control system will deny usage in the event that requestdatagrams go unanswered after a predetermined period of time (which mayindicate an unauthorized attempt to use the licensed product). In thissystem, usage is managed at a central location by the responsedatagrams. So for example if license fees have not been paid, access tothe licensed product is terminated.

It is argued by Griswold that the described system is advantageousbecause it can be implemented entirely in software. However, the systemdescribed by Griswold has limitations. An important limitation is thatduring the use of the licensed product, the user must always be coupledto an appropriate communication facility in order to send and receivedatagrams. This creates a dependency on the communication facility. Soif the communication facility is not available, the licensed productcannot be used. Moreover, some party must absorb the cost ofcommunicating with the license server.

A system for controlling the distribution of digitally encoded books isembodied in a system available from VPR Systems, LTD. of St. Louis,Miss. The VPR system is self-contained and is comprised of: (1) point ofsale kiosks for storing and downloading of books, (2) personal storagemediums (cartridges) to which the books are downloaded, and (3) readersfor viewing the book. In a purchase transaction, a purchaser willpurchase a voucher card representing the desired book. The voucher willcontain sufficient information to identify the book purchased andperhaps some demographic information relating to the sales transaction.To download the book, the voucher and the cartridge are inserted intothe kiosk.

The VPR system may also be used as a library. In such an embodiment, thekiosk manages the number of “copies” that may be checked out at onetime. Further, the copy of the book is erased from the user's cartridgeafter a certain check-out time has expired. However, individuals cannotloan books because the cartridges may only be used with the owner'sreader.

The foregoing distribution and protection schemes operate in part bypreventing subsequent distribution of the work. While this certainlyprevents unauthorized distributions, it does so by sacrificing thepotential for subsequent revenue bearing uses. For example, it may bedesirable to allow the lending of a purchased work to permit exposure ofthe work to potential buyers. Another example would be to permit thecreation of a derivative work for a fee. Yet another example would be topermit copying the work for a fee (essentially purchasing it). Thus, itwould be desirable to provide flexibility in how the owner of a digitalwork may allow it to be distributed.

While flexibility in distribution is a concern, the owners of a workwant to make sure they are paid for such distributions. In U.S. Pat. No.4,977,594 to Shear, entitled “Database Usage Metering and ProtectionSystem and Method,” a system for metering and billing for usage ofinformation distributed on a CD-ROM is described. The system requiresthe addition of a billing module to the computer system. The billingmodule may operate in a number of different ways. First, it mayperiodically communicate billing data to a central billing facility,whereupon the user may be billed. Second, billing may occur bydisconnecting the billing module and the user sending it to a centralbilling facility where the data is read and a user bill generated.

U.S. Pat. No. 5,247,575, Sprague et al., entitled “InformationDistribution System”, describes an information distribution system whichprovides and charges only for user selected information. A plurality ofencrypted information packages (IPs) are provided at the user site, viahigh and/or low density storage media and/or by broadcast transmission.Some of the IPs may be of no interest to the user. The IPs of interestare selected by the user and are decrypted and stored locally. The IPsmay be printed, displayed or even copied to other storage media. Thecharges for the selected IP's are accumulated within a user apparatusand periodically reported by telephone to a central accounting facility.The central accounting facility also issues keys to decrypt the IPs. Thekeys are changed periodically. If the central accounting facility hasnot issued a new key for a particular user station, the station isunable to retrieve information from the system when the key is changed.

A system available from Wave Systems Corp. of Princeton, N.Y., providesfor metering of software usage on a personal computer. The system isinstalled onto a computer and collects information on what software isin use, encrypts it and then transmits the information to a transactioncenter. From the transaction center, a bill is generated and sent to theuser. The transaction center also maintains customer accounts so thatlicensing fees may be forwarded directly to the software providers.Software operating under this system must be modified so that usage canbe accounted.

Known techniques for billing do not provide for billing of copies madeof the work. For example, if data is copied from the CD-ROM described inShear, any subsequent use of the copy of the information cannot bemetered or billed. In other words, the means for billing runs with themedia rather than the underlying work. It would be desirable to have adistribution system where the means for billing is always transportedwith the work.

SUMMARY OF THE INVENTION

A method, system and software for controlling the number of times that ausage right associated with a digital work can be exercised isdisclosed, including creating a digital work; determining a usage rightfor the digital work, the usage right specifying a digital ticket, thedigital ticket indicating a number of times the usage right may beexercised; requesting access to the digital work including anidentification of the usage right; determining the validity of the usageright based on a number of times the digital ticket has been used;granting or denying access to the digital work based on the result ofthe determining step; and updating the digital ticket if access to thedigital work is granted.

In further embodiments, a system for controlling the distribution anduse of digital works using digital tickets is disclosed. A ticket is anindicator that the ticket holder has already paid for or is otherwiseentitled to some specified right, product or service. In the presentinvention, a “digital ticket” is used to enable the ticket holder toexercise usage rights specifying the requirement of the digital ticket.Usage rights are used to define how a digital work may be used ordistributed. Specific instances of usage rights are used to indicate aparticular manner of use or distribution. A usage right may specify adigital ticket which must be present before the right may be exercised.For example, a digital ticket may be specified in a Copy right of adigital work, so that exercise of the Copy right requires the party thatdesires a copy of the digital work be in possession of the necessarydigital ticket. After a copy of the digital work is successfully sent tothe requesting party, the digital ticket is “punched” to indicate that acopy of the digital work has been made. When the ticket is “punched” apredetermined number of times, it may no longer be used.

Digital works are stored in repositories. Repositories enforce the usagerights for digital works. Each repository has a “generic ticket agent”which punches tickets. In some instances only the generic ticket agentis necessary. In other instances, punching by a “special ticket agent”residing on another repository may be desired. Punching by a “specialticket agent” enables greater security and control of the digital work.For example, it can help prevent digital ticket forgery. Special ticketagents are also useful in situations where an external database needs tobe updated or checked.

A digital ticket is merely an instance of a digital work. Thus, adigital ticket may be distributed among repositories in the same fashionas other digital works.

A digital ticket may be used in many commercial scenarios such as in thepurchase of software and prepaid upgrades. A digital ticket may also beused to limit the number of times that a right may be exercised. Forexample, a user may purchase a copy of a digital work, along with theright to make up to 5 Copies. In this case, the Copy right would haveassociated therewith a digital ticket that can be punched up to 5 times.Other such commercial scenarios will become apparent from the detaileddescription.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flowchart illustrating a simple instantiation of theoperation of the currently preferred embodiment of the presentinvention.

FIG. 2 is a block diagram illustrating the various repository types andthe repository transaction flow between them in the currently preferredembodiment of the present invention.

FIG. 3 is a block diagram of a repository coupled with a credit serverin the currently preferred embodiment of the present invention.

FIGS. 4 a and 4 b are examples of rendering systems as may be utilizedin the currently preferred embodiment of the present invention.

FIG. 5 illustrates a contents file layout for a digital work as may beutilized in the currently preferred embodiment of the present invention.

FIG. 6 illustrates a contents file layout for an individual digital workof the digital work of FIG. 5 as may be utilized in the currentlypreferred embodiment of the present invention.

FIG. 7 illustrates the components of a description block of thecurrently preferred embodiment of the present invention.

FIG. 8 illustrates a description tree for the contents file layout ofthe digital work illustrated in FIG. 5.

FIG. 9 illustrates a portion of a description tree corresponding to theindividual digital work illustrated in FIG. 6.

FIG. 10 illustrates a layout for the rights portion of a descriptionblock as may be utilized in the currently preferred embodiment of thepresent invention.

FIG. 11 is a description tree wherein certain d-blocks have PRINT usagerights and is used to illustrate “strict” and “lenient” rules forresolving usage rights conflicts.

FIG. 12 is a block diagram of the hardware components of a repository asare utilized in the currently preferred embodiment of the presentinvention.

FIG. 13 is a block diagram of the functional (logical) components of arepository as are utilized in the currently preferred embodiment of thepresent invention.

FIG. 14 is diagram illustrating the basic components of a usage right inthe currently preferred embodiment of the present invention.

FIG. 15 lists the usage rights grammar of the currently preferredembodiment of the present invention.

FIG. 16 is a flowchart illustrating the steps of certificate delivery,hotlist checking and performance testing as performed in a registrationtransaction as may be performed in the currently preferred embodiment ofthe present invention.

FIG. 17 is a flowchart illustrating the steps of session informationexchange and clock synchronization as may be performed in the currentlypreferred embodiment of the present invention, after each repository inthe registration transaction has successfully completed the stepsdescribed in FIG. 16.

FIG. 18 is a flowchart illustrating the basic flow for a usagetransaction, including the common opening and closing step, as may beperformed in the currently preferred embodiment of the presentinvention.

FIG. 19 is a state diagram of server and client repositories inaccordance with a transport protocol followed when moving a digital workfrom the server to the client repositories, as may be performed in thecurrently preferred embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT Overview

A system for controlling use and distribution of digital works isdisclosed. The present invention is directed to supporting commercialtransactions involving digital works. The transition to digital worksprofoundly and fundamentally changes how creativity and commerce canwork. It changes the cost of transporting or storing works becausedigital property is almost “massless.” Digital property can betransported at electronic speeds and requires almost no warehousing.Keeping an unlimited supply of virtual copies on hand requiresessentially no more space than keeping one copy on hand. The digitalmedium also lowers the costs of alteration, reuse and billing.

There is a market for digital works because creators are stronglymotivated to reuse portions of digital works from others rather thancreating their own completely. This is because it is usually so mucheasier to use an existing stock photo or music clip than to create a newone from scratch.

Herein the terms “digital work”, “work” and “content” refer to any workthat has been reduced to a digital representation. This would includeany audio, video, text, or multimedia work and any accompanyinginterpreter (e.g. software) that may be required for recreating thework. The term composite work refers to a digital work comprised of acollection of other digital works. The term “usage rights” or “rights”is a term which refers to rights granted to a recipient of a digitalwork. Generally, these rights define how a digital work can be used andif it can be further distributed. Each usage right may have one or morespecified conditions which must be satisfied before the right may beexercised. Appendix 1 provides a Glossary of the terms used herein.

A key feature of the present invention is that usage rights arepermanently “attached” to the digital work. Copies made of a digitalwork will also have usage rights attached. Thus, the usage rights andany associated fees assigned by a creator and subsequent distributorwill always remain with a digital work.

The enforcement elements of the present invention are embodied inrepositories. Among other things, repositories are used to store digitalworks, control access to digital works, bill for access to digital worksand maintain the security and integrity of the system.

The combination of attached usage rights and repositories enabledistinct advantages over prior systems. As noted in the prior art,payment of fees are primarily for the initial access. In suchapproaches, once a work has been read, computational control over thatcopy is gone. Metaphorically, “the content genie is out of the bottleand no more fees can be billed.” In contrast, the present inventionnever separates the fee descriptions from the work. Thus, the digitalwork genie only moves from one trusted bottle (repository) to another,and all uses of copies are potentially controlled and billable.

FIG. 1 is a high level flowchart omitting various details but whichdemonstrates the basic operation of the present invention. Referring toFIG. 1, a creator creates a digital work, step 101. The creator willthen determine appropriate usage rights and fees, attach them to thedigital work, and store them in Repository 1, step 102. Thedetermination of appropriate usage rights and fees will depend onvarious economic factors. The digital work remains securely inRepository 1 until a request for access is received. The request foraccess begins with a session initiation by another repository. Here aRepository 2 initiates a session with Repository 1, step 103. As will bedescribed in greater detail below, this session initiation includessteps which help to insure that the respective repositories aretrustworthy. Assuming that a session can be established, Repository 2may then request access to the Digital Work for a stated purpose, step104. The purpose may be, for example, to print the digital work or toobtain a copy of the digital work. The purpose will correspond to aspecific usage right. In any event, Repository 1 checks the usage rightsassociated with the digital work to determine if the access to thedigital work may be granted, step 105. The check of the usage rightsessentially involves a determination of whether a right associated withthe access request has been attached to the digital work and if allconditions associated with the right are satisfied. If the access isdenied, repository 1 terminates the session with an error message, step106. If access is granted, repository 1 transmits the digital work torepository 2, step 107. Once the digital work has been transmitted torepository 2, repository 1 and 2 each generate billing information forthe access which is transmitted to a credit server, step 108. Suchdouble billing reporting is done to insure against attempts tocircumvent the billing process.

FIG. 2 illustrates the basic interactions between repository types inthe present invention. As will become apparent from FIG. 2, the variousrepository types will serve different functions. It is fundamental thatrepositories will share a core set of functionality which will enablesecure and trusted communications. Referring to FIG. 2, a repository 201represents the general instance of a repository. The repository 201 hastwo modes of operation; a server mode and a requester mode. When in theserver mode, the repository will be receiving and processing accessrequests to digital works. When in the requester mode, the repositorywill be initiating requests to access digital works. Repository 201 isgeneral in the sense that its primary purpose is as an exchange mediumfor digital works. During the course of operation, the repository 201may communicate with a plurality of other repositories, namelyauthorization repository 202, rendering repository 203 and masterrepository 204. Communication between repositories occurs utilizing arepository transaction protocol 205.

Communication with an authorization repository 202 may occur when adigital work being accessed has a condition requiring an authorization.Conceptually, an authorization is a digital certificate such thatpossession of the certificate is required to gain access to the digitalwork. An authorization is itself a digital work that can be movedbetween repositories and subjected to fees and usage rights conditions.An authorization may be required by both repositories involved in anaccess to a digital work.

Communication with a rendering repository 203 occurs in connection withthe rendering of a digital work. As will be described in greater detailbelow, a rendering repository is coupled with a rendering device (e.g. aprinter device) to comprise a rendering system.

Communication with a master repository 205 occurs in connection withobtaining an identification certificate. Identification certificates arethe means by which a repository is identified as “trustworthy”. The useof identification certificates is described below with respect to theregistration transaction.

FIG. 3 illustrates the repository 201 coupled to a credit server 301.The credit server 301 is a device which accumulates billing informationfor the repository 201. The credit server 301 communicates withrepository 201 via billing transactions 302 to record billingtransactions. Billing transactions are reported to a billingclearinghouse 303 by the credit server 301 on a periodic basis. Thecredit server 301 communicates to the billing clearinghouse 303 viaclearinghouse transactions 304. The clearinghouse transactions 304enable a secure and encrypted transmission of information to the billingclearinghouse 303.

Rendering Systems

A rendering system is generally defined as a system comprising arepository and a rendering device which can render a digital work intoits desired form. Examples of a rendering system may be a computersystem, a digital audio system, or a printer. A rendering system has thesame security features as a repository. The coupling of a renderingrepository with the rendering device may occur in a manner suitable forthe type of rendering device.

FIG. 4 a illustrates a printer as an example of a rendering system.Referring to FIG. 4, printer system 401 has contained therein a printerrepository 402 and a print device 403. It should be noted that thedashed line defining printer system 401 defines a secure systemboundary. Communications within the boundary is assumed to be secure.Depending on the security level, the boundary also represents a barrierintended to provide physical integrity. The printer repository 402 is aninstantiation of the rendering repository 205 of FIG. 2. The printerrepository 402 will in some instances contain an ephemeral copy of adigital work which remains until it is printed out by the print engine403. In other instances, the printer repository 402 may contain digitalworks such as fonts, which will remain and can be billed based on use.This design assures that all communication lines between printers andprinting devices are encrypted, unless they are within a physicallysecure boundary. This design feature eliminates a potential “fault”point through which the digital work could be improperly obtained. Theprinter device 403 represents the printer components used to create theprinted output.

Also illustrated in FIG. 4 a is the repository 404. The repository 404is coupled to the printer repository 402. The repository 404 representsan external repository which contains digital works.

FIG. 4 b is an example of a computer system as a rendering system. Acomputer system may constitute a “multi-function” device since it mayexecute digital works (e.g. software programs) and display digital works(e.g. a digitized photograph). Logically, each rendering device can beviewed as having its own repository, although only one physicalrepository is needed. Referring to FIG. 4 b, a computer system 410 hascontained therein a display/execution repository 411. Thedisplay/execution repository 411 is coupled to display device, 412 andexecution device 413. The dashed box surrounding the computer system 410represents a security boundary within which communications are assumedto be secure. The display/execution repository 411 is further coupled toa credit server 414 to report any fees to be billed for access to adigital work and a repository 415 for accessing digital works storedtherein.

Structure of Digital Works

Usage rights are attached directly to digital works. Thus, it isimportant to understand the structure of a digital work. The structureof a digital work, in particular composite digital works, may benaturally organized into an acyclic structure such as a hierarchy. Forexample, a magazine has various articles and photographs which may havebeen created and are owned by different persons. Each of the articlesand photographs may represent a node in a hierarchical structure.Consequently, controls, i.e. usage rights, may be placed on each node bythe creator. By enabling control and fee billing to be associated witheach node, a creator of a work can be assured that the rights and feesare not circumvented.

In the currently preferred embodiment, the file information for adigital work is divided into two files: a “contents” file and a“description tree” file. From the perspective of a repository, the“contents” file is a stream of addressable bytes whose format dependscompletely on the interpreter used to play, display or print the digitalwork. The description tree file makes it possible to examine the rightsand fees for a work without reference to the content of the digitalwork. It should be noted that the term description tree as used hereinrefers to any type of acyclic structure used to represent therelationship between the various components of a digital work.

FIG. 5 illustrates the layout of a contents file. Referring to FIG. 5, adigital work 509 is comprised of story A 510, advertisement 511, story B512 and story C 513. It is assumed that the digital work is storedstarting at a relative address of 0. Each of the parts of the digitalwork are stored linearly so that story A 510 is stored at approximatelyaddresses 0-30,000, advertisement 511 at addresses 30,001-40,000, storyB 512 at addresses 40,001-60,000 and story C 513 at addresses60,001-85K. The detail of story A 510 is illustrated in FIG. 6.Referring to FIG. 6, the story A 510 is further broken down to show text614 stored at address 0-1500, soldier photo 615 at addresses1501-10,000, graphics 616 stored at addresses 10,001-25,000 and sidebar617 stored address 25,001-30,000. Note that the data in the contentsfile may be compressed (for saving storage) or encrypted (for security).

From FIGS. 5 and 6 it is readily observed that a digital work can berepresented by its component parts as a hierarchy. The description treefor a digital work is comprised of a set of related descriptor blocks(d-blocks). The contents of each d-block are described with respect toFIG. 7. Referring to FIG. 7, a d-block 700 includes an identifier 701which is a unique identifier for the work in the repository, a startingaddress 702 providing the start address of the first byte of the work, alength 703 giving the number of bytes in the work, a rights portion 704wherein the granted usage rights and their status data are maintained, aparent pointer 705 for pointing to a parent d-block and child pointers706 for pointing to the child d-blocks. In the currently preferredembodiment, the identifier 701 has two parts. The first part is a uniquenumber assigned to the repository upon manufacture. The second part is aunique number assigned to the work upon creation. The rights portion 704will contain a data structure, such as a look-up table, wherein thevarious information associated with a right is maintained. Theinformation required by the respective usage rights is described in moredetail below. D-blocks form a strict hierarchy. The top d-block of awork has no parent; all other d-blocks have one parent. The relationshipof usage rights between parent and child d-blocks and how conflicts areresolved is described below.

A special type of d-block is a “shell” d-block. A shell d-block adds nonew content beyond the content of its parts. A shell d-block is used toadd rights and fee information, typically by distributors of digitalworks.

FIG. 8 illustrates a description tree for the digital work of FIG. 5.Referring to FIG. 8, a top d-block 820 for the digital work points tothe various stories and advertisements contained therein. Here, the topd-block 820 points to d-block 821 (representing story A 510), d-block822 (representing the advertisement 511), d-block 823 (representingstory B 512) and d-block 824 (representing story C 513).

The portion of the description tree for Story A 510 is illustrated inFIG. 9. D-block 925 represents text 614, d-block 926 represents photo615, d-block 927 represents graphics 616 by and d-block 928 representssidebar 617.

The rights portion 704 of a descriptor block is further illustrated inFIG. 10. FIG. 10 illustrates a structure which is repeated in the rightsportion 704 for each right. Referring to FIG. 10, each right will have aright code field 1001 and status information field 1002. The right codefield 1001 will contain a unique code assigned to a right. The statusinformation field 1002 will contain information relating to the state ofa right and the digital work. Such information is indicated below inTable 1. The rights as stored in the rights portion 304 may typically bein numerical order based on the right code.

The approach for representing digital works by separating descriptiondata from content assumes that parts of a file are contiguous but takesno position on the actual representation of content. In particular, itis neutral to the question of whether content representation may take anobject oriented approach. It would be natural to represent content asobjects. In principle, it may be convenient to have content objects thatinclude the billing structure and rights information that is representedin the d-blocks. Such variations in the design of the representation arepossible and are viable alternatives but may introduce processingoverhead, e.g. the interpretation of the objects. TABLE 1 DIGITAL WORKSTATE INFORMATION Property Value Use Copies-in- Number A counter of thenumber of copies of a Use work that are in use. Incremented when anothercopy is used; decremented when use is completed. Loan-Period Time-UnitsIndicator of the maximum number of time-units that a document can beloaned out Loaner-Copy Boolean Indicator that the current work is aloaned out copy of an authorized digital work. Remaining- Time-UnitsIndicator of the remaining time of use Time on a metered document right.Document- String A string containing various identifying Descrinformation about a document. The exact format of this is not specified,but it can include information such as a publisher name, author name,ISBN number, and so on. Revenue- RO-Descr A handle identifying a revenueowner Owner for a digital, work. This is used for reporting usage fees.Publication- Date-Descr The date that the digital work was Datepublished. History-list History-Rec A list of events recording therepostories and dates for operations that copy, transfer, backup, orrestore a digital work.

Digital works are stored in a repository as part of a hierarchical filesystem. Folders (also termed directories and sub-directories) containthe digital works as well as other folders. Digital works and folders ina folder are ordered in alphabetical order. The digital works are typedto reflect how the files are used. Usage rights can be attached tofolders so that the folder itself is treated as a digital work. Accessto the folder would then be handled in the same fashion as any otherdigital work As will be described in more detail below, the contents ofthe folder are subject to their own rights. Moreover, file managementrights may be attached to the folder which defines how folder contentscan be managed.

Attaching Usage Rights to a Digital Work

It is fundamental to the present invention that the usage rights aretreated as part of the digital work. As the digital work is distributed,the scope of the granted usage rights will remain the same or may benarrowed. For example, when a digital work is transferred from adocument server to a repository, the usage rights may include the rightto loan a copy for a predetermined period of time (called the originalrights). When the repository loans out a copy of the digital work, theusage rights in the loaner copy (called the next set of rights) could beset to prohibit any further rights to loan out the copy. The basic ideais that one cannot grant more rights than they have.

The attachment of usage rights into a digital work may occur in avariety of ways. If the usage rights will be the same for an entiredigital work, they could be attached when the digital work is processedfor deposit in the digital work server. In the case of a digital workhaving different usage rights for the various components, this can bedone as the digital work is being created. An authoring tool or digitalwork assembling tool could be utilized which provides for an automatedprocess of attaching the usage rights.

As will be described below, when a digital work is copied, transferredor loaned, a “next set of rights” can be specified. The “next set ofrights” will be attached to the digital work as it is transported.

Resolving Conflicting Rights

Because each part of a digital work may have its own usage rights, therewill be instances where the rights of a “contained part” are differentfrom its parent or container part. As a result, conflict rules must beestablished to dictate when and how a right may be exercised. Thehierarchical structure of a digital work facilitates the enforcement ofsuch rules. A “strict” rule would be as follows: a right for a part in adigital work is sanctioned if and only if it is sanctioned for the part,for ancestor d-blocks containing the part and for all descendentd-blocks. By sanctioned, it is meant that (1) each of the respectiveparts must have the right, and (2) any conditions for exercising theright are satisfied.

It also possible to implement the present invention using a more lenientrule. In the more lenient rule, access to the part may be enabled to thedescendent parts which have the right, but access is denied to thedescendents which do not.

Example of applying both the strict rule and lenient is illustrated withreference to FIG. 11. Referring to FIG. 11, a root d-block 1101 haschild d-blocks 1102-1105. In this case, root d-block represents amagazine, and each of the child d-blocks 1102-1105 represent articles inthe magazine. Suppose that a request is made to PRINT the digital workrepresented by root d-block 1101 wherein the strict rule is followed.The rights for the root d-block 1101 and child d-blocks 1102-1105 arethen examined. Root d-block 1101 and child d-blocks 1102 and 1105 havebeen granted PRINT rights. Child d-block 1103 has not been granted PRINTrights and child d-block 1104 has PRINT rights conditioned on payment ofa usage fee.

Under the strict rule the PRINT right cannot be exercised because thechild d-block does not have the PRINT right. Under the lenient rule, theresult would be different. The digital works represented by childd-blocks 1102 and 1105 could be printed and the digital work representedby d-block 1104 could be printed so long as the usage fee is paid. Onlythe digital work represented by d-block 1103 could not be printed. Thissame result would be accomplished under the strict rule if the requestswere directed to each of the individual digital works.

The present invention supports various combinations of allowing anddisallowing access. Moreover, as will be described below, the usagerights grammar permits the owner of a digital work to specify ifconstraints may be imposed on the work by a container part. The mannerin which digital works may be sanctioned because of usage rightsconflicts would be implementation specific and would depend on thenature of the digital works.

Repositories

Many of the powerful functions of repositories—such as their ability to“loan” digital works or automatically handle the commercial reuse ofdigital works—are possible because they are trusted systems. The systemsare trusted because they are able to take responsibility for fairly andreliably carrying out the commercial transactions. That the systems canbe responsible (“able to respond”) is fundamentally an issue ofintegrity. The integrity of repositories has three parts: physicalintegrity, communications integrity, and behavioral integrity.

Physical integrity refers to the integrity of the physical devicesthemselves. Physical integrity applies both to the repositories and tothe protected digital works. Thus, the higher security classes ofrepositories themselves may have sensors that detect when tampering isattempted on their secure cases. In addition to protection of therepository itself, the repository design protects access to the contentof digital works. In contrast with the design of conventional magneticand optical devices—such as floppy disks, CD-ROMs, andvideotapes—repositories never allow non-trusted systems to access theworks directly. A maker of generic computer systems cannot guaranteethat their platform will not be used to make unauthorized copies. Themanufacturer provides generic capabilities for reading and writinginformation, and the general nature of the functionality of the generalcomputing device depends on it. Thus, a copy program can copy arbitrarydata. This copying issue is not limited to general purpose computers. Italso arises for the unauthorized duplication of entertainment “software”such as video and audio recordings by magnetic recorders. Again, thefunctionality of the recorders depends on their ability to copy and theyhave no means to check whether a copy is authorized. In contrast,repositories prevent access to the raw data by general devices and cantest explicit rights and conditions before copying or otherwise grantingaccess. Information is only accessed by protocol between trustedrepositories.

Communications integrity refers to the integrity of the communicationschannels between repositories. Roughly speaking, communicationsintegrity means that repositories cannot be easily fooled by “tellingthem lies.” Integrity in this case refers to the property thatrepositories will only communicate with other devices that are able topresent proof that they are certified repositories, and furthermore,that the repositories monitor the communications to detect “impostors”and malicious or accidental interference. Thus the security measuresinvolving encryption, exchange of digital certificates, and noncesdescribed below are all security measures aimed at reliablecommunication in a world known to contain active adversaries.

Behavioral integrity refers to the integrity in what repositories do.What repositories do is determined by the software that they execute.The integrity of the software is generally assured only by knowledge ofits source. Restated, a user will trust software purchased at areputable computer store but not trust software obtained off a random(insecure) server on a network. Behavioral integrity is maintained byrequiring that repository software be certified and be distributed withproof of such certification, i.e. a digital certificate. The purpose ofthe certificate is to authenticate that the software has been tested byan authorized organization, which attests that the software does what itis supposed to do and that it does not compromise the behavioralintegrity of a repository. If the digital certificate cannot be found inthe digital work or the master repository which generated thecertificate is not known to the repository receiving the software, thenthe software cannot be installed.

In the description of FIG. 2, it was indicated that repositories come invarious forms. All repositories provide a core set of services for thetransmission of digital works. The manner in which digital works areexchanged is the basis for all transaction between repositories. Thevarious repository types differ in the ultimate functions that theyperform. Repositories may be devices themselves, or they may beincorporated into other systems. An example is the rendering repository205 of FIG. 2.

A repository will have associated with it a repository identifier.Typically, the repository identifier would be a unique number assignedto the repository at the time of manufacture. Each repository will alsobe classified as being in a particular security class. Certaincommunications and transactions may be conditioned on a repository beingin a particular security class. The various security classes aredescribed in greater detail below.

As a prerequisite to operation, a repository will require possession ofan identification certificate. Identification certificates are encryptedto prevent forgery and are issued by a Master repository. A masterrepository plays the role of an authorization agent to enablerepositories to receive digital works. Identification certificates mustbe updated on a periodic basis. Identification certificates aredescribed in greater detail below with respect to the registrationtransaction.

A repository has both a hardware and functional embodiment. Thefunctional embodiment is typically software executing on the hardwareembodiment. Alternatively, the functional embodiment may be embedded inthe hardware embodiment such as an Application Specific IntegratedCircuit (ASIC) chip.

The hardware embodiment of a repository will be enclosed in a securehousing which if compromised, may cause the repository to be disabled.The basic components of the hardware embodiment of a repository aredescribed with reference to FIG. 12. Referring to FIG. 12, a repositoryis comprised of a processing means 1200, storage system 1207, clock 1205and external interface 1206. The processing means 1200 is comprised of aprocessor element 1201 and processor memory 1202. The processing means1201 provides controller, repository transaction and usage rightstransaction functions for the repository. Various functions in theoperation of the repository such as decryption and/or decompression ofdigital works and transaction messages are also performed by theprocessing means 1200. The processor element 1201 may be amicroprocessor or other suitable computing component. The processormemory 1202 would typically be further comprised of Read Only Memories(ROM) and Random Access Memories (RAM). Such memories would contain thesoftware instructions utilized by the processor element 1201 inperforming the functions of the repository.

The storage system 1207 is further comprised of descriptor storage 1203and content storage 1204. The description tree storage 1203 will storethe description tree for the digital work and the content storage willstore the associated content. The description tree storage 1203 andcontent storage 1204 need not be of the same type of storage medium, norare they necessarily on the same physical device. So for example, thedescriptor storage 1203 may be stored on a solid state storage (forrapid retrieval of the description tree information), while the contentstorage 1204 may be on a high capacity storage such as an optical disk.

The clock 1205 is used to time-stamp various time based conditions forusage rights or for metering usage fees which may be associated with thedigital works. The clock 1205 will have an uninterruptible power supply,e.g. a battery, in order to maintain the integrity of the time-stamps.The external interface means 1206 provides for the signal connection toother repositories and to a credit server. The external interface means1206 provides for the exchange of signals via such standard interfacessuch as RS-232 or Personal Computer Manufacturers Card IndustryAssociation (PCMCIA) standards, or FDDI. The external interface means1206 may also provide network connectivity.

The functional embodiment of a repository is described with reference toFIG. 13. Referring to FIG. 13, the functional embodiment is comprised ofan operating system 1301, core repository services 1302, usagetransaction handlers 1303, repository specific functions, 1304 and auser interface 1305. The operating system 1301 is specific to therepository and would typically depend on the type of processor beingused. The operating system 1301 would also provide the basic servicesfor controlling and interfacing between the basic components of therepository.

The core repository services 1302 comprise a set of functions requiredby each and every repository. The core repository services 1302 includethe session initiation transactions which are defined in greater detailbelow. This set of services also includes a generic ticket agent whichis used to “punch” a digital ticket and a generic authorization serverfor processing authorization specifications. Digital tickets andauthorizations are specific mechanisms for controlling the distributionand use of digital works and are described and more detail below. Notethat coupled to the core repository services are a plurality ofidentification certificates 1306. The identification certificates 1306are required to enable the use of the repository.

The usage transactions handler 1303 comprise functionality forprocessing access requests to digital works and for billing fees basedon access. The usage transactions supported will be different for eachrepository type. For example, it may not be necessary for somerepositories to handle access requests for digital works.

The repository specific functionality 1304 comprises functionality thatis unique to a repository. For example, the master repository hasspecial functionality for issuing digital certificates and maintainingencryption keys. The repository specific functionality 1304 wouldinclude the user interface implementation for the repository.

Repository Security Classes

For some digital works the losses caused by any individual instance ofunauthorized copying is insignificant and the chief economic concernlies in assuring the convenience of access and low-overhead billing. Insuch cases, simple and inexpensive handheld repositories andnetwork-based workstations may be suitable repositories, even though themeasures and guarantees of security are modest.

At the other extreme, some digital works such as a digital copy of afirst run movie or a bearer bond or stock certificate would be of veryhigh value so that it is prudent to employ caution and fairly elaboratesecurity measures to ensure that they are not copied or forged. Arepository suitable for holding such a digital work could have elaboratemeasures for ensuring physical integrity and for verifying authorizationbefore use.

By arranging a universal protocol, all kinds of repositories cancommunicate with each other in principle. However, creators of someworks will want to specify that their works will only be transferred torepositories whose level of security is high enough. For this reason,document repositories have a ranking system for classes and levels ofsecurity. The security classes in the currently preferred embodiment aredescribed in Table 2. TABLE 2 REPOSITORY SECURITY LEVELS LevelDescription of Security 0 Open system. Document transmission isunencrypted. No digital certificate is required for identification. Thesecurity of the system depends mostly on user honesty, since only modestknowledge may be needed to circumvent the security measures. Therepository has no provisions for preventing unauthorized programs fromrunning and accessing or copying files. The system does not prevent theuse of removable storage and does not encrypt stored files. 1 Minimalsecurity. Like the previous class except that stored files are minimallyencrypted, including ones on removable storage. 2 Basic security. Likethe previous class except that special tools and knowledge are requiredto compromise the programming, the contents of the repository, or thestate of the clock. All digital communications are encrypted. A digitalcertificate is provided as identification. Medium level encryption isused. Repository identification number is unforgeable. 3 Generalsecurity. Like the previous class plus the requirement of special toolsare needed to compromise the physical integrity of the repository andthat modest encryption is used on all transmissions. Password protectionis required to use the local user interface. The digital clock systemcannot be reset without authorization. No works would be stored onremovable storage. When executing works as programs, it runs them intheir own address space and does not give them direct access to any filestorage or other memory containing system code or works. They can accessworks only through the transmission transaction protocol. 4 Like theprevious class except that high level encryption is used on allcommunications. Sensors are used to record attempts at physical andelectronic tampering. After such tampering, the repository will notperform other transactions until it has reported such tampering to adesignated server. 5 Like the previous class except that if the physicalor digital attempts at tampering exceed some preset thresholds thatthreaten the physical integrity of the repository or the integrity ofdigital and cryptographic barriers, then the repository will save onlydocument description records of history but will erase or destroy anydigital identifiers that could be misused if released to an unscrupulousparty. It also modifies any certificates of authenticity to indicatethat the physical system has been compromised. It also erases thecontents of designated documents. 6 Like the previous class except thatthe repository will attempt wireless communication to report tamperingand will employ noisy alarms. 10 This would correspond to a very highlevel of security. This server would maintain constant communications toremote security systems reporting transactions, sensor readings, andattempts to circumvent security.

The characterization of security levels described in Table 2 is notintended to be fixed. More important is the idea of having differentsecurity levels for different repositories. It is anticipated that newsecurity classes and requirements will evolve according to socialsituations and changes in technology.

Repository User Interface

A user interface is broadly defined as the mechanism by which a userinteracts with a repository in order to invoke transactions to gainaccess to a digital work, or exercise usage rights. As described above,a repository may be embodied in various forms. The user interface for arepository will differ depending on the particular embodiment. The userinterface may be a graphical user interface having icons representingthe digital works and the various transactions that may be performed.The user interface may be a generated dialog in which a user is promptedfor information.

The user interface itself need not be part of the repository. As arepository may be embedded in some other device, the user interface maymerely be a part of the device in which the repository is embedded. Forexample, the repository could be embedded in a “card” that is insertedinto an available slot in a computer system. The user interface may becombination of a display, keyboard, cursor control device and softwareexecuting on the computer system.

At a minimum, the user interface must permit a user to input informationsuch as access requests and alpha numeric data and provide feedback asto transaction status. The user interface will then cause the repositoryto initiate the suitable transactions to service the request. Otherfacets of a particular user interface will depend on the functionalitythat a repository will provide.

Credit Servers

In the present invention, fees may be associated with the exercise of aright. The requirement for payment of fees is described with eachversion of a usage right in the usage rights language. The recording andreporting of such fees is performed by the credit server. One of thecapabilities enabled by associating fees with rights is the possibilityof supporting a wide range of charging models. The simplest model, usedby conventional software, is that there is a single fee at the time ofpurchase, after which the purchaser obtains unlimited rights to use thework as often and for as long as he or she wants. Alternative models,include metered use and variable fees. A single work can have differentfees for different uses. For example, viewing a photograph on a displaycould have different fees than making a hardcopy or including it in anewly created work. A key to these alternative charging models is tohave a low overhead means of establishing fees and accounting for crediton these transactions.

A credit server is a computational system that reliably authorizes andrecords these transactions so that fees are billed and paid. The creditserver reports fees to a billing clearinghouse. The billingclearinghouse manages the financial transactions as they occur. As aresult, bills may be generated and accounts reconciled. Preferably, thecredit server would store the fee transactions and periodicallycommunicate via a network with billing clearinghouse for reconciliation.In such an embodiment, communications with the billing clearinghousewould be encrypted for integrity and security reasons. In anotherembodiment, the credit server acts as a “debit card” where transactionsoccur in “real-time” against a user account.

A credit server is comprised of memory, a processing means, a clock, andinterface means for coupling to a repository and a financial institution(e.g. a modem). The credit server will also need to have security andauthentication functionality. These elements are essentially the sameelements as those of a repository. Thus, a single device can be both arepository and a credit server, provided that it has the appropriateprocessing elements for carrying out the corresponding functions andprotocols. Typically, however, a credit server would be a card-sizedsystem in the possession of the owner of the credit. The credit serveris coupled to a repository and would interact via financial transactionsas described below. Interactions with a financial institution may occurvia protocols established by the financial institutions themselves.

In the currently preferred embodiment credit servers associated withboth the server and the repository report the financial transaction tothe billing clearinghouse. For example, when a digital work is copied byone repository to another for a fee, credit servers coupled to each ofthe repositories will report the transaction to the billingclearinghouse. This is desirable in that it insures that a transactionwill be accounted for in the event of some break in the communicationbetween a credit server and the billing clearinghouse. However, someimplementations may embody only a single credit server reporting thetransaction to minimize transaction processing at the risk of losingsome transactions.

Usage Rights Language

The present invention uses statements in a high level “usage rightslanguage” to define rights associated with digital works and theirparts. Usage rights statements are interpreted by repositories and areused to determine what transactions can be successfully carried out fora digital work and also to determine parameters for those transactions.For example, sentences in the language determine whether a given digitalwork can be copied, when and how it can be used, and what fees (if any)are to be charged for that use. Once the usage rights statements aregenerated, they are encoded in a suitable form for accessing during theprocessing of transactions.

Defining usage rights in terms of a language in combination with thehierarchical representation of a digital work enables the support of awide variety of distribution and fee schemes. An example is the abilityto attach multiple versions of a right to a work. So a creator mayattach a PRINT right to make 5 copies for $10.00 and a PRINT right tomake unlimited copies for $100.00. A purchaser may then choose whichoption best fits his needs. Another example is that rights and fees areadditive. So in the case of a composite work, the rights and fees ofeach of the components works is used in determining the rights and feesfor the work as a whole. Other features and benefits of the usage rightslanguage will become apparent in the description of distribution and usescenarios provided below.

The basic contents of a right are illustrated in FIG. 14. Referring toFIG. 14, a right 1450 has a transactional component 1451 and aspecifications component 1452. A right 1450 has a label (e.g. COPY orPRINT) which indicate the use or distribution privileges that areembodied by the right. The transactional component 1451 corresponds to aparticular way in which a digital work may be used or distributed. Thetransactional component 1451 is typically embodied in softwareinstructions in a repository which implement the use or distributionprivileges for the right. The specifications components 1452 are used tospecify conditions which must be satisfied prior to the right beingexercised or to designate various transaction related parameters. In thecurrently preferred embodiment, these specifications include copy count1453, Fees and Incentives 1454, Time 1455, Access and Security 1456 andControl 1457. Each of these specifications will be described in greaterdetail below with respect to the language grammar elements.

The usage rights language is based on the grammar described below. Agrammar is a convenient means for defining valid sequence of symbols fora language. In describing the grammar the notation “[a|b|c]” is used toindicate distinct choices among alternatives. In this example, asentence can have either an “a”, “b” or “c”. It must include exactly oneof them. The braces { } are used to indicate optional items. Note thatbrackets, bars and braces are used to describe the language of usagerights sentences but do not appear in actual sentences in the language.

In contrast, parentheses are part of the usage rights language.Parentheses are used to group items together in lists. The notation (x*)is used to indicate a variable length list, that is, a list containingone or more items of type x. The notation (x)* is used to indicate avariable number of lists containing x.

Keywords in the grammar are words followed by colons. Keywords are acommon and very special case in the language. They are often used toindicate a single value, typically an identifier. In many cases, thekeyword and the parameter are entirely optional. When a keyword isgiven, it often takes a single identifier as its value. In some cases,the keyword takes a list of identifiers.

In the usage rights language, time is specified in anhours:minutes:seconds (or hh:mm:ss) representation. Time zoneindicators, e.g. PDT for Pacific Daylight Time, may also be specified.Dates are represented as year/month/day (or YYYY/MMM/DD). Note thatthese time and date representations may specify moments in time or unitsof time Money units are specified in terms of dollars.

Finally, in the usage rights language, various “things” will need tointeract with each other. For example, an instance of a usage right mayspecify a bank account, a digital ticket, etc. Such things need to beidentified and are specified herein using the suffix “-ID.”

The Usage Rights Grammar is listed in it's entirety in FIG. 15 and isdescribed below.

Grammar element 1501 “Digital Work Rights:=(Rights*)” define the digitalwork rights as a set of rights. The-set of rights attached to a digitalwork define how that digital work may be transferred, used, performed orplayed. A set of rights will attach to the entire digital work and inthe case of compound digital works, each of the components of thedigital work. The usage rights of components of a digital may bedifferent.

Grammar element 1502 “Right:=(Right-Code {Copy-Count} {Control-Spec}{Time-Spec} {Access-Spec} {Fee-Spec})” enumerates the content of aright. Each usage right must specify a right code. Each right may alsooptionally specify conditions which must be satisfied before the rightcan be exercised. These conditions are copy count, control, time, accessand fee conditions. In the currently preferred embodiment, for theoptional elements, the following defaults apply: copy count equals 1, notime limit on the use of the right, no access tests or a security levelrequired to use the right and no fee is required. These conditions willeach be described in greater detail below.

It is important to note that a digital work may have multiple versionsof a right, each having the same right code. The multiple versions wouldprovide alternative conditions and fees for accessing the digital work.

A Grammar element 1503“Right-Code:=Render-Code|Transport-Code|File-Management-Code|Derivative-Works-CodeConfiguration-Code” distinguishes each of the specific rights into aparticular right type (although each right is identified by distinctright codes). In this way, the grammar provides a catalog of possiblerights that can be associated with parts of digital works. In thefollowing, rights are divided into categories for convenience indescribing them.

Grammar element 1504 “Render-Code:=[Play: {Player: Player-ID}|Print:{Printer: Printer-ID}]” lists a category of rights all involving themaking of ephemeral, transitory, or non-digital copies of the digitalwork. After use the copies are erased.

Play: A process of rendering or performing a digital work on someprocessor. This includes such things as playing digital movies, playingdigital music, playing a video game, running a computer program, ordisplaying a document on a display.

Print: To render the work in a medium that is not further protected byusage rights, such as printing on paper.

Grammar element 1505 “Transport-Code:=[Copy|Transfer|Loan{Remaining-Rights: Next-Set-of-Rights}]{(Next-Copy-Rights: Next-Set ofRights)}” lists a category of rights involving the making of persistent,usable copies of the digital work on other repositories. The optionalNext-Copy-Rights determine the rights on the work after it istransported. If this is not specified, then the rights on thetransported copy are the same as on the original. The optionalRemaining-Rights specify the rights that remain with a digital work whenit is loaned out. If this is not specified, then the default is that norights can be exercised when it is loaned out.

Copy: Make a new copy of a work

Transfer: Moving a work from one repository to another.

Loan: Temporarily loaning a copy to another repository for a specifiedperiod of time.

Grammar element 1506 “File-Management-Code:=Backup {Back-Up-Copy-Rights:Next-Set-of Rights}|Restore|Delete|Folder|Directory{Name:Hide-Local|Hide-Remote}{Parts:Hide-Local|Hide-Remote}” lists acategory of rights involving operations for file management, such as themaking of backup copies to protect the copy owner against catastrophicequipment failure.

Many software licenses and also copyright law give a copy owner theright to make backup copies to protect against catastrophic failure ofequipment. However, the making of uncontrolled backup copies isinherently at odds with the ability to control usage, since anuncontrolled backup copy can be kept and then restored even after theauthorized copy was sold.

The File management rights enable the making and restoring of backupcopies in a way that respects usage rights, honoring the requirements ofboth the copy owner and the rights grantor and revenue owner. Backupcopies of work descriptions (including usage rights and fee data) can besent under appropriate protocol and usage rights control to otherdocument repositories of sufficiently high security. Further rightspermit organization of digital works into folders which themselves aretreated as digital works and whose contents may be “hidden” from a partyseeking to determine the contents of a repository.

Backup: To make a backup copy of a digital work as protection againstmedia failure.

Restore: To restore a backup copy of a digital work.

Delete: To delete or erase a copy of a digital work.

Folder: To create and name folders, and to move files and foldersbetween folders.

Directory: To hide a folder or it's contents.

Grammar element 1507 “Derivative-Works-Code: [Extract|Embed|Edit{Process: Process-ID}] {Next-Copy-Rights: Next-Set-of Rights}” lists acategory of rights involving the use of a digital work to create newworks.

Extract: To remove a portion of a work, for the purposes of creating anew work.

Embed: To include a work in an existing work.

Edit: To alter a digital work by copying, selecting and modifyingportions of an existing digital work.

Grammar element 1508 “Configuration-Code:=Install|Uninstall” lists acategory of rights for installing and uninstalling software on arepository (typically a rendering repository.) This would typicallyoccur for the installation of a new type of player within the renderingrepository.

Install: To install new software on a repository.

Uninstall: To remove existing software from a repository.

Grammar element 1509 “Next-Set-of-Rights:={(Add: Set-Of-Rights)}{(Delete: Set-Of-Rights)} {(Replace: Set-Of-Rights)} {(Keep:Set-Of-Rights)}” defines how rights are carried forward for a copy of adigital work. If the Next-Copy-Rights is not specified, the rights forthe next copy are the same as those of the current copy. Otherwise, theset of rights for the next copy can be specified. Versions of rightsafter Add: are added to the current set of rights. Rights after Delete:are deleted from the current set of rights. If only right codes arelisted after Delete:, then all versions of rights with those codes aredeleted. Versions of rights after Replace: subsume all versions ofrights of the same type in the current set of rights.

If Remaining-Rights is not specified, then there are no rights for theoriginal after all Loan copies are loaned out. If Remaining-Rights isspecified, then the Keep: token can be used to simplify the expressionof what rights to keep behind. A list of right codes following keepmeans that all of the versions of those listed rights are kept in theremaining copy. This specification can be overridden by subsequentDelete: or Replace: specifications.

Copy Count Specification

For various transactions, it may be desirable to provide some limit asto the number of “copies” of the work which may be exercisedsimultaneously for the right. For example, it may be desirable to limitthe number of copies of a digital work that may be loaned out at a timeor viewed at a time.

Grammar element 1510 “Copy-Count:=(Copies:positive-integer|0|unlimited)” provides a condition which defines thenumber of “copies” of a work subject to the right. A copy count can be0, a fixed number, or unlimited. The copy-count is associated with eachright, as opposed to there being just a single copy-count for thedigital work. The Copy-Count for a right is decremented each time that aright is exercised. When the Copy-Count equals zero, the right can nolonger be exercised. If the Copy-Count is not specified, the default isone.

Control Specification

Rights and fees depend in general on rights granted by the creator aswell as further restrictions imposed by later distributors. Controlspecifications deal with interactions between the creators and theirdistributors governing the imposition of further restrictions and fees.For example, a distributor of a digital work may not want an endconsumer of a digital work to add fees or otherwise profit bycommercially exploiting the purchased digital work.

Grammar element 1511 “Control-Spec:=(Control:{Restrictable|Unrestrictable} {Unchargeable|Chargeable}-)” provides acondition to specify the effect of usage rights and fees of parents onthe exercise of the right. A digital work is restrictable if higherlevel d-blocks can impose further restrictions (time specifications andaccess specifications) on the right. It is unrestrictable if no furtherrestrictions can be imposed. The default setting is restrictable. Aright is unchargeable if no more fees can be imposed on the use of theright. It is chargeable if more fees can be imposed. The default ischargeable.

Time Specification

It is often desirable to assign a start date or specify some duration asto when a right may be exercised. Grammar element 1512“Time-Spec:=({Fixed-Interval|Sliding-Interval|Meter-Tim-e} Until:Expiration-Date)” provides for specification of time conditions on theexercise of a right. Rights may be granted for a specified time.Different kinds of time specifications are appropriate for differentkinds of rights. Some rights may be exercised during a fixed andpredetermined duration. Some rights may be exercised for an intervalthat starts the first time that the right is invoked by sometransaction. Some rights may be exercised or are charged according tosome kind of metered time, which may be split into separate intervals.For example, a right to view a picture for an hour might be split intosix ten minute viewings or four fifteen minute viewings or twenty threeminute viewings.

The terms “time” and “date” are used synonymously to refer to a momentin time. There are several kinds of time specifications. Eachspecification represents some limitation on the times over which theusage right applies. The Expiration-Date specifies the moment at whichthe usage right ends. For example, if the Expiration-Date is “Jan. 1,1995,” then the right ends at the first moment of 1995. If theExpiration-Date is specified as *forever*, then the rights areinterpreted as continuing without end. If only an expiration date isgiven, then the right can be exercised as often as desired until theexpiration date.

Grammar element 1513 “Fixed-Interval:=From: Start-Time” is used todefine a predetermined interval that runs from the start time to theexpiration date.

Grammar element 1514 “Sliding-Interval:=Interval: Use-Duration” is usedto define an indeterminate (or “open”) start time. It sets limits on acontinuous period of time over which the contents are accessible. Theperiod starts on the first access and ends after the duration has passedor the expiration date is reached, whichever comes first. For example,if the right gives 10 hours of continuous access, the use-duration wouldbegin when the first access was made and end 10 hours later.

Grammar element 1515 “Meter-Time:=Time-Remaining: Remaining-Use” is usedto define a “meter time,” that is, a measure of the time that the rightis actually exercised. It differs from the Sliding-Intervalspecification in that the time that the digital work is in use need notbe continuous. For example, if the rights guarantee three days ofaccess, those days could be spread out over a month. With thisspecification, the rights can be exercised until the meter time isexhausted or the expiration date is reached, whichever comes first.

Remaining-Use:=Time-Unit

Start-Time:=Time-Unit

Use-Duration:=Time-Unit

All of the time specifications include time-unit specifications in theirultimate instantiation.

Security Class and Authorization Specification

The present invention provides for various security mechanisms to beintroduced into a distribution or use scheme. Grammar element 1516“Access-Spec:=({SC: Security-Class} {Authorization: Authorization-ID*}{Other-Authorization: Authorization-ID*} {Ticket: Ticket-ID})” providesa means for restricting access and transmission. Access specificationscan specify a required security class for a repository to exercise aright or a required authorization test that must be satisfied.

The keyword “SC:” is used to specify a minimum security level for therepositories involved in the access. If “SC:” is not specified, thelowest security level is acceptable.

The optional “Authorization:” keyword is used to specify requiredauthorizations on the same repository as the work. The optional“Other-Authorization:” keyword is used to specify requiredauthorizations on the other repository in the transaction.

The optional “Ticket:” keyword specifies the identity of a ticketrequired for the transaction. A transaction involving digital ticketsmust locate an appropriate digital ticket agent who can “punch” orotherwise validate the ticket before the transaction can proceed.Tickets are described in greater detail below.

In a transaction involving a repository and a document server, someusage rights may require that the repository have a particularauthorization, that the server have some authorization, or that bothrepositories have (possibly different) authorizations. Authorizationsthemselves are digital works (hereinafter referred to as anauthorization object) that can be moved between repositories in the samemanner as other digital works. Their copying and transferring is subjectto the same rights and fees as other digital works. A repository is saidto have an authorization if that authorization object is containedwithin the repository.

In some cases, an authorization may be required from a source other thanthe document server and repository. An authorization object referencedby an Authorization-ID can contain digital address information to beused to set up a communications link between a repository and theauthorization source. These are analogous to phone numbers. For suchaccess tests, the communication would need to be established andauthorization obtained before the right could be exercised.

For one-time usage rights, a variant on this scheme is to have a digitalticket. A ticket is presented to a digital ticket agent, whose type isspecified on the ticket. In the simplest case, a certified genericticket agent, available on all repositories, is available to “punch” theticket. In other cases, the ticket may contain addressing informationfor locating a “special” ticket agent. Once a ticket has been punched,it cannot be used again for the same kind of transaction (unless it isunpunched or refreshed in the manner described below.) Punching includesmarking the ticket with a timestamp of the date and time it was used.Tickets are digital works and can be copied or transferred betweenrepositories according to their usage rights.

In the currently preferred embodiment, a “punched” ticket becomes“unpunched” or “refreshed” when it is copied or extracted. The Copy andExtract operations save the date and time as a property of the digitalticket. When a ticket agent is given a ticket, it can simply checkwhether the digital copy was made after the last time that it waspunched. Of course, the digital ticket must have the copy or extractusage rights attached thereto.

The capability to unpunch a ticket is important in the following cases:

A digital work is circulated at low cost with a limitation that it canbe used only once.

A digital work is circulated with a ticket that can be used once to givediscounts on purchases of other works.

A digital work is circulated with a ticket (included in the purchaseprice and possibly embedded in the work) that can be used for a futureupgrade.

In each of these cases, if a paid copy is made of the digital work(including the ticket) the new owner would expect to get a fresh(unpunched) ticket, whether the copy seller has used the work or not. Incontrast, loaning a work or simply transferring it to another repositoryshould not revitalize the ticket.

Usage Fees and Incentives Specification

The billing for use of a digital work is fundamental to a commercialdistribution system. Grammar Element 1517“Fee-Spec:={Scheduled-Discount}Regular-Fee-Spec|Scheduled-Fee-Spec|Markup-Spec” provides a range ofoptions for billing for the use of digital works.

A key feature of this approach is the development of low-overheadbilling for transactions in potentially small amounts. Thus, it becomesfeasible to collect fees of only a few cents each for thousands oftransactions.

The grammar differentiates between uses where the charge is per use fromthose where it is metered by the time unit. Transactions can supportfees that the user pays for using a digital work as well as incentivespaid by the right grantor to users to induce them to use or distributethe digital work.

The optional scheduled discount refers to the rest of the feespecification—discounting it by a percentage over time. If it is notspecified, then there is no scheduled discount. Regular feespecifications are constant over time. Scheduled fee specifications givea schedule of dates over which the fee specifications change. Markupspecifications are used in d-blocks for adding a percentage to the feesalready being charged.

Grammar Element 1518 “Scheduled-Discount:=(Scheduled-Discount:(Time-Spec Percentage)*)” A Scheduled-Discount is essentially ascheduled modifier of any other fee specification for this version ofthe right of the digital work. (It does not refer to children or parentdigital works or to other versions of rights.). It is a list of pairs oftimes and percentages. The most recent time in the list that has not yetpassed at the time of the transaction is the one in effect. Thepercentage gives the discount percentage. For example, the number 10refers to a 10% discount.

Grammar Element 1519 “Regular-Fee-Spec:=({Fee:|Incentive:}[Per-Use-Spec|Metered-Rate-Spec|Best-Price-Spec|Call-For-Price-Spec]{Min: Money-Unit Per: Time-Spec} {Max: Money-Unit Per: Time-Spec} To:Account-ID)” provides for several kinds of fee specifications.

Fees are paid by the copy-owner/user to the revenue-owner if Fee: isspecified. Incentives are paid by the revenue-owner to the user ifIncentive: is specified. If the Min: specification is given, then thereis a minimum fee to be charged per time-spec unit for its use. If theMax: specification is given, then there is a maximum fee to be chargedper time-spec for its use. When Fee: is specified, Account-ID identifiesthe account to which the fee is to be paid. When Incentive: isspecified, Account-ID identifies the account from which the fee is to bepaid.

Grammar element 1520 “Per-Use-Spec:=Per-Use: Money-unit” defines asimple fee to be paid every time the right is exercised, regardless ofhow much time the transaction takes.

Grammar element 1521 “Metered-Rate-Spec:=Metered: Money-Unit Per:Time-Spec” defines a metered-rate fee paid according to how long theright is exercised. Thus, the time it takes to complete the transactiondetermines the fee.

Grammar, element 1522 “Best-Price-Spec:=Best-Price: Money-unit Max:Money-unit” is used to specify a best-price that is determined when theaccount is settled. This specification is to accommodate special deals,rebates, and pricing that depends on information that is not availableto the repository. All fee specifications can be combined with ticketsor authorizations that could indicate that the consumer is a wholesaleror that he is a preferred customer, or that the seller be authorized insome way. The amount of money in the Max: field is the maximum amountthat the use will cost. This is the amount that is tentatively debitedfrom the credit server. However, when the transaction is ultimatelyreconciled, any excess amount will be returned to the consumer in aseparate transaction.

Grammar element 1523 “Call-For-Price-Spec:=Call-For-Price” is similar toa “Best-Price-Spec” in that it is intended to accommodate cases whereprices are dynamic. A Call-For-Price Spec requires a communication witha dealer to determine the price. This option cannot be exercised if therepository cannot communicate with a dealer at the time that the rightis exercised. It is based on a secure transaction whereby the dealernames a price to exercise the right and passes along a deal certificatewhich is referenced or included in the billing process.

Grammar element 1524 “Scheduled-Fee-Spec:=(Schedule: (Time-SpecRegular-Fee-Spec)*)” is used to provide a schedule of dates over whichthe fee specifications change. The fee specification with the mostrecent date not in the future is the one that is in effect. This issimilar to but more general than the scheduled discount. It is moregeneral, because it provides a means to vary the fee agreement for eachtime period.

Grammar element 1525 “Markup-Spec:=Markup: percentage To: Account-ID” isprovided for adding a percentage to the fees already being charged. Forexample, a 5% markup means that a fee of 5% of cumulative fee so farwill be allocated to the distributor. A markup specification can beapplied to all of the other kinds of fee specifications. It is typicallyused in a shell provided by a distributor. It refers to fees associatedwith d-blocks that are parts of the current d-block. This might be aconvenient specification for use in taxes, or in distributor overhead.

Examples of Sets of Usage Rights

((Play) (Transfer (SC: 3)) (Delete)

This work can be played without requirements for fee or authorization onany rendering system. It can be transferred to any other repository ofsecurity level 3 or greater. It can be deleted.

((Play) (Transfer (SC: 3)) (Delete) (Backup) (Restore (Fee:Per-Use: $5To: Account-ID-678)))

Same as the previous example plus rights for backup and restore. Thework can be backed up without fee. It can be restored for a $5 feepayable to the account described by Account-ID-678.

((Play) (Transfer (SC: 3))

(Copy (SC:3)(Fee: Per-Use: $5 To: Account-ID-678))

(Delete (Incentive: Per-Use: $2.50 To: Account-ID-678)))

This work can be played, transferred, copied, or deleted. Copy ortransfer operations can take place only with repositories of securitylevel three or greater. The fee to make a copy is $5 payable toAccount-ID-678. If a copy is deleted, then an incentive of $2.50 is paidto the former copy owner.

((Play) (Transfer (SC: 3))

Copy (SC: 3) (Fee: Per-Use: $10 To: Account-ID-678))

Delete) (Backup) (Restore (SC: 3) (Fee: Per-Use: $5 To:Account-ID-678)))

Same as the previous example plus fees for copying. The work can becopied digitally for a fee of $10 payable to Account-ID-678. Therepository on which the work is copied or restored must be at securitylevel 3 or greater.

((Play) (Transfer (SC: 3))

(Copy Authorization: License-123-ID (SC: 3)))

The digital work can be played, transferred, or copied. Copies ortransfers must be on repositories of security level 3 or greater.Copying requires the license License-123-ID issued to the copyingrepository. None of the rights require fees.

((Play) (Print Printer: Printer-567-ID (Fee: Per-Use: $1 To:Account-ID-678)))

This work can be played for free. It can be printed on any printer withthe identifier Printer-567-ID for a fee of $1 payable to the accountdescribed by Account-ID-678.

((Play Player: Player-876-ID) (From: Feb. 2, 1994 Until: Feb. 15, 1995)(Fee: Metered: $0.01 Per: 0:1:0 Min: $0.25 Per: 0/1/0 To:Account-ID-567))

This work can be played on any player holding the ID Player-876-ID. Thetime of this right is from Feb. 14, 1994 until Feb. 15, 1995. The feefor use is one cent per minute with a minimum of 25 cents in any daythat it is used, payable to the account described by Account-ID-567.

((Play) (Transfer) (Delete)(Loan 2 (Delete: Transfer Loan)))

This work can be played, transferred, deleted, or loaned. Up to twocopies can be loaned out at a time. The loaned copy has the same rightsexcept that it cannot be transferred. When both copies are loaned out,no rights can be exercised on the original on the repository.

((Play) (Transfer) (Delete) (Backup) (Restore (SC:3))

(Loan 2 Remaining-Copy-Rights: (Delete: Play Transfer)

Next-Set-of-Rights: (Delete: Transfer Loan)))

Similar to previous example. Rights to Backup and Restore the work areadded, where restoration requires a repository of at least securitylevel three. When all copies of the work are loaned out, the remainingcopy cannot be played or transferred.

((Play) (Transfer) (Copy) (Print) (Backup) (Restore (SC:3))

(Loan 1Remaining-Copy-Rights: (Add: Play Print Backup)

Next-Set-of-Rights: (Delete: Transfer Loan)

(Fee: Metered: $10 Per: 1:0:0 To: Account-ID-567))

(Loan 1 Remaining-Copy-Rights:

Add: ((Play Player: Player-876-ID) 2 (From: Feb. 14, 1994 Until: Feb.15, 1995)

(Fee: Metered: $0.01 Per: 0:1:0 Min: $0.25 Per: 0/1/0

To: Account-ID-567))))

The original work has rights to Play, Transfer, Copy, Print, Backup,Restore, and Loan. There are two versions of the Loan right. The firstversion of the loan right costs $10 per day but allows the original copyowner to exercise free use of the Play, Print and Backup rights. Thesecond version of the Loan right is free. None of the original rightsare applicable. However a right to Play the work at the specifiedmetered rate is added.

((Play Player: Player-Small-Screen-123-ID)

(Embed (Fee: Per-Use $0.01 To: Account-678-ID))

(Copy (Fee: Per-Use $1.00 To: Account-678-ID)))

The digital work can be played on any player with the identifierPlayer-Small-Screen-123-ID. It can be embedded in a larger work. Theembedding requires a modest one cent registration fee to Account-678-ID.Digital copies can be made for $1.00.

Repository Transactions

When a user requests access to a digital work, the repository willinitiate various transactions. The combination of transactions invokedwill depend on the specifications assigned for a usage right. There arethree basic types of transactions, Session Initiation Transactions,Financial Transactions and Usage Transactions. Generally, sessioninitiation transactions are initiated first to establish a validsession. When a valid session is established, transactions correspondingto the various usage rights are invoked. Finally, request specifictransactions are performed.

Transactions occur between two repositories (one acting as a server),between a repository and a document playback platform (e.g. forexecuting or viewing), between a repository and a credit server orbetween a repository and an authorization server. When transactionsoccur between more than one repository, it is assumed that there is areliable communication channel between the repositories. For example,this could be a TCP/IP channel or any other commercially availablechannel that has built-in capabilities for detecting and correctingtransmission errors. However, it is not assumed that the communicationchannel is secure. Provisions for security and privacy are part of therequirements for specifying and implementing repositories and thus formthe need for various transactions.

Message Transmission

Transactions require that there be some communication betweenrepositories. Communication between repositories occurs in units termedas messages. Because the communication line is assumed to be unsecure,all communications with repositories that are above the lowest securityclass are encrypted utilizing a public key encryption technique. Publickey encryption is a well known technique in the encryption arts. Theterm key refers to a numeric code that is used with encryption anddecryption algorithms. Keys come in pairs, where “writing keys” are usedto encrypt data and “checking keys” are used to decrypt data. Bothwriting and checking keys may be public or private. Public keys arethose that are distributed to others. Private keys are maintained inconfidence.

Key management and security is instrumental in the success of a publickey encryption system. In the currently preferred embodiment, one ormore master repositories maintain the keys and create the identificationcertificates used by the repositories.

When a sending repository transmits a message to a receiving repository,the sending repository encrypts all of its data using the public writingkey of the receiving repository. The sending repository includes itsname, the name of the receiving repository, a session identifier such asa nonce (described below), and a message counter in each message.

In this way, the communication can only be read (to a high probability)by the receiving repository, which holds the private checking key fordecryption. The auxiliary data is used to guard against various replayattacks to security. If messages ever arrive with the wrong counter oran old nonce, the repositories can assume that someone is interferingwith communication and the transaction terminated.

The respective public keys for the repositories to be used forencryption are obtained in the registration transaction described below.

Session Initiation Transactions

A usage transaction is carried out in a session between repositories.For usage transactions involving more than one repository, or forfinancial transactions between a repository and a credit server, aregistration transaction is performed. A second transaction termed alogin transaction, may also be needed to initiate the session. The goalof the registration transaction is to establish a secure channel betweentwo repositories who know each others identities. As it is assumed thatthe communication channel between the repositories is reliable but notsecure, there is a risk that a non-repository may mimic the protocol inorder to gain illegitimate access to a repository.

The registration transaction between two repositories is described withrespect to FIGS. 16 and 17. The steps described are from the perspectiveof a “repository-1” registering its identity with a “repository-2”. Theregistration must be symmetrical so the same set of steps will berepeated for repository-2 registering its identity with repository-1.Referring to FIG. 16, repository-1 first generates an encryptedregistration identifier, step 1601 and then generates a registrationmessage, step 1602. A registration message is comprised of an identifierof a master repository, the identification certificate for therepository-1 and an encrypted random registration identifier. Theidentification certificate is encrypted by the master repository in itsprivate key and attests to the fact that the repository (hererepository-1) is a bona fide repository. The identification certificatealso contains a public key for the repository, the repository securitylevel and a timestamp (indicating a time after which the certificate isno longer valid.) The registration identifier is a number generated bythe repository for this registration. The registration identifier isunique to the session and is encrypted in repository-1's private key.The registration identifier is used to improve security ofauthentication by detecting certain kinds of communications basedattacks. Repository-1 then transmits the registration message torepository-2, step 1603.

Upon receiving the registration message, repository-2 determines if ithas the needed public key for the master repository, step 1604. Ifrepository-2 does not have the needed public key to decrypt theidentification certificate, the registration transaction terminates inan error, step 1618.

Assuming that repository-2 has the proper public key the identificationcertificate is decrypted, step 1605. Repository-2 saves the encryptedregistration identifier, step 1606, and extracts the repositoryidentifier, step 1607. The extracted repository identifier is checkedagainst a “hotlist” of compromised document repositories, step 1608. Inthe currently preferred embodiment, each repository will contain“hotlists” of compromised repositories. If the repository is on the“hotlist”, the registration transaction terminates in an error per step1618. Repositories can be removed from the hotlist when theircertificates expire, so that the list does not need to grow withoutbound. Also, by keeping a short list of hotlist certificates that it haspreviously received, a repository can avoid the work of actually goingthrough the list. These lists would be encrypted by a master repository.A minor variation on the approach to improve efficiency would have therepositories first exchange lists of names of hotlist certificates,ultimately exchanging only those lists that they had not previouslyreceived. The “hotlists” are maintained and distributed by Masterrepositories.

Note that rather than terminating in error, the transaction couldrequest that another registration message be sent based on anidentification certificate created by another master repository. Thismay be repeated until a satisfactory identification certificate isfound, or it is determined that trust cannot be established.

Assuming that the repository is not on the hotlist, the repositoryidentification needs to be verified. In other words, repository-2 needsto validate that the repository on the other end is really repository-1.This is termed performance testing and is performed in order to avoidinvalid access to the repository via a counterfeit repository replayinga recording of a prior session initiation between repository-1 andrepository-2. Performance testing is initiated by repository-2generating a performance message, step 1609. The performance messageconsists of a nonce, the names of the respective repositories, the timeand the registration identifier received from repository-1. A nonce is agenerated message based on some random and variable information (e.g.the time or the temperature.) The nonce is used to check whetherrepository-1 can actually exhibit correct encrypting of a message usingthe private keys it claims to have, on a message that it has never seenbefore. The performance message is encrypted using the public keyspecified in the registration message of repository-1. The performancemessage is transmitted to repository-1, step 1610, where it is decryptedby repository-1 using its private key, step 1611. Repository-1 thenchecks to make sure that the names of the two repositories are correct,step 1612, that the time is accurate, step 1613 and that theregistration identifier corresponds to the one it sent, step 1614. Ifany of these tests fails, the transaction is terminated per step 1616.Assuming that the tests are passed, repository-1 transmits the nonce torepository-2 in the clear, step 1615. Repository-2 then compares thereceived nonce to the original nonce, step 1617. If they are notidentical, the registration transaction terminates in an error per step1618. If they are the same, the registration transaction hassuccessfully completed.

At this point, assuming that the transaction has not terminated, therepositories exchange messages containing session keys to be used in allcommunications during the session and synchronize their clocks. FIG. 17illustrates the session information exchange and clock synchronizationsteps (again from the perspective of repository-1.) Referring to FIG.17, repository-1 creates a session key pair, step 1701. A first key iskept private and is used by repository-1 to encrypt messages. The secondkey is a public key used by repository-2 to decrypt messages. The secondkey is encrypted using the public key of repository-2, step 1702 and issent to repository-2, step 1703. Upon receipt, repository-2 decrypts thesecond key, step 1704. The second key is used to decrypt messages insubsequent communications. When each repository has completed this step,they are both convinced that the other repository is bona fide and thatthey are communicating with the original. Each repository has given theother a key to be used in decrypting further communications during thesession. Since that key is itself transmitted in the public key of thereceiving repository only it will be able to decrypt the key which isused to decrypt subsequent messages.

After the session information is exchanged, the repositories mustsynchronize their clocks. Clock synchronization is used by therepositories to establish an agreed upon time base for the financialrecords of their mutual transactions. Referring back to FIG. 17,repository-2 initiates clock synchronization by generating a time stampexchange message, step 1705, and transmits it to repository-1, step1706. Upon receipt, repository-1 generates its own time stamp message,step 1707 and transmits it back to repository-2, step 1708. Repository-2notes the current time, step 1709 and stores the time received fromrepository-1, step 1710. The current time is compared to the timereceived from repository-1, step 1711. The difference is then checked tosee if it exceeds a predetermined tolerance (e.g. one minute), step1712. If it does, repository-2 terminates the transaction as this mayindicate tampering with the repository, step 1713. If not repository-2computes an adjusted time delta, step 1714. The adjusted time delta isthe difference between the clock time of repository-2 and the average ofthe times from repository-1 and repository-2.

To achieve greater accuracy, repository-2 can request the time again upto a fixed number of times (e.g. five times), repeat the clocksynchronization steps, and average the results.

A second session initiation transaction is a Login transaction. TheLogin transaction is used to check the authenticity of a user requestinga transaction. A Login transaction is particularly prudent for theauthorization of financial transactions that will be charged to a creditserver. The Login transaction involves an interaction between the userat a user interface and the credit server associated with a repository.The information exchanged here is a login string supplied by therepository/credit server to identify itself to the user, and a PersonalIdentification Number (PIN) provided by the user to identify himself tothe credit server. In the event that the user is accessing a creditserver on a repository different from the one on which the userinterface resides, exchange of the information would be encrypted usingthe public and private keys of the respective repositories.

Billing Transactions

Billing Transactions are concerned with monetary transaction with acredit server. Billing Transactions are carried out when all otherconditions are satisfied and a usage fee is required for granting therequest. For the most part, billing transactions are well understood inthe state of the art. These transactions are between a repository and acredit server, or between a credit server and a billing clearinghouse.Briefly, the required transactions include the following:

Registration and LOGIN transactions, by which the repository and userestablish their bona fides to a credit server. These transactions wouldbe entirely internal in cases where the repository and credit server areimplemented as a single system.

Registration and LOGIN transactions, by which a credit serverestablishes its bona fides to a billing clearinghouse.

An Assign-fee transaction to assign a charge. The information in thistransaction would include a transaction identifier, the identities ofthe repositories in the transaction, and a list of charges from theparts of the digital work. If there has been any unusual event in thetransaction such as an interruption of communications, that informationis included as well.

A Begin-charges transaction to assign a charge. This transaction is muchthe same as an assign-fee transaction except that it is used for metereduse. It includes the same information as the assign-fee 4, iitransaction as well as the usage fee information. The credit-server isthen responsible for running a clock.

An End-charges transaction to end a charge for metered use. (In avariation on this approach, the repositories would exchange periodiccharge information for each block of time.)

A report-charges transaction between a personal credit server and abilling clearinghouse. This transaction is invoked at least once perbilling period. It is used to pass along information about charges. Ondebit and credit cards, this transaction would also be used to updatebalance information and credit limits as needed.

All billing transactions are given a transaction ID and are reported tothe credit severs by both the server and the client. This reducespossible loss of billing information if one of the parties to atransaction loses a banking card and provides a check against tamperingwith the system.

Usage Transactions

After the session initiation transactions have been completed, the usagerequest may then be processed. To simplify the description of the stepscarried out in processing a usage request, the term requester is used torefer to a repository in the requester mode which is initiating arequest, and the term server is used to refer to a repository in theserver mode and which contains the desired digital work. In many casessuch as requests to print or view a work, the requester and server maybe the same device and the transactions described in the following wouldbe entirely internal. In such instances, certain transaction steps, suchas the registration transaction, need not be performed.

There are some common steps that are part of the semantics of all of theusage rights transactions. These steps are referred to as the commontransaction steps. There are two sets—the “opening” steps and the“closing” steps. For simplicity, these are listed here rather thanrepeating them in the descriptions of all of the usage rightstransactions.

Transactions can refer to a part of a digital work, a complete digitalwork, or a Digital work containing other digital works. Although notdescribed in detail herein, a transaction may even refer to a foldercomprised of a plurality of digital works. The term “work” is used torefer to what ever portion or set of digital works is being accessed.

Many of the steps here involve determining if certain conditions aresatisfied. Recall that each usage right may have one or more conditionswhich must be satisfied before the right can be exercised. Digital workshave parts and parts have parts. Different parts can have differentrights and fees. Thus, it is necessary to verify that the requirementsare met for ALL of the parts that are involved in a transaction Forbrevity, when reference is made to checking whether the rights exist andconditions for exercising are satisfied, it is meant that all suchchecking takes place for each of the relevant parts of the work.

FIG. 18 illustrates the initial common opening and closing steps for atransaction. At this point it is assumed that registration has occurredand that a “trusted” session is in place. General tests are tests onusage rights associated with the folder containing the work or somecontaining folder higher in the file system hierarchy. These testscorrespond to requirements imposed on the work as a consequence of itsbeing on the particular repository, as opposed to being attached to thework itself. Referring to FIG. 18, prior to initiating a usagetransaction, the requester performs any general tests that are requiredbefore the right associated with the transaction can be exercised, step,1801. For example, install, uninstall and delete rights may beimplemented to require that a requester have an authorizationcertificate before the right can be exercised. Another example is therequirement that a digital ticket be present and punched before adigital work may be copied to a requester. If any of the general testsfail, the transaction is not initiated, step, 1802. Assuming that suchrequired tests are passed, upon receiving the usage request, the servergenerates a transaction identifier that is used in records or reports ofthe transaction, step 1803. The server then checks whether the digitalwork has been granted the right corresponding to the requestedtransaction, step 1804. If the digital work has not been granted theright corresponding to the request, the transaction terminates, step1805. If the digital work has been granted the requested right, theserver then determines if the various conditions for exercising theright are satisfied. Time based conditions are examined, step 1806.These conditions are checked by examining the time specification for theversion of the right. If any of the conditions are not satisfied, thetransaction terminates per step 1805.

Assuming that the time based conditions are satisfied, the server checkssecurity and access conditions, step 1807. Such security and accessconditions are satisfied if: 1) the requester is at the specifiedsecurity class, or a higher security class, 2) the server satisfies anyspecified authorization test and 3) the requester satisfies anyspecified authorization tests and has any required digital tickets. Ifany of the conditions are not satisfied, the transaction terminates perstep 1805.

Assuming that the security and access conditions are all satisfied, theserver checks the copy count condition, step 1808. If the copy countequals zero, then the transaction cannot be completed and thetransaction terminates per step 1805.

Assuming that the copy count does not equal zero, the server checks ifthe copies in use for the requested right is greater than or equal toany copy count for the requested right (or relevant parts), step 1809.If the copies in use are greater than or equal to the copy count, thisindicates that usage rights for the version of the transaction have beenexhausted. Accordingly, the server terminates the transaction, step1805. If the copy count is less than the copies in use for thetransaction the transaction can continue, and the copies in use would beincremented by the number of digital works requested in the transaction,step 1810.

The server then checks if the digital work has a “Loan” access right,step 1811. The “Loan” access right is a special case since remainingrights may be present even though all copies are loaned out. If thedigital work has the “Loan” access right, a check is made to see if allcopies have been loaned out, step 1812. The number of copies that couldbe loaned is the sum of the Copy-Counts for all of the versions of theloan right of the digital work. For a composite work, the relevantfigure is the minimal such sum of each of the components of thecomposite work. If all copies have been loaned out, the remaining rightsare determined, step 1813. The remaining-rights are determined from theremaining rights specifications from the versions of the Loan right. Ifthere is only one version of the Loan right, then the determination issimple. The remaining rights are the ones specified in that version ofthe Loan right, or none if Remaining-Rights: is not specified. If thereare multiple versions of the Loan right and all copies of all of theversions are loaned out, then the remaining rights is taken as theminimum set (intersection) of remaining rights across all of theversions of the loan right. The server then determines if the requestedright is in the set of remaining rights, step 1814. If the requestedright is not in the set of remaining rights, the server terminates thetransaction, step 1805.

If Loan is not a usage right for the digital work or if all copies havenot been loaned out or the requested right is in the set of remainingrights, fee conditions for the right are then checked, step 1815. Thiswill initiate various financial transactions between the repository andassociated credit server. Further, any metering of usage of a digitalwork will commence. If any financial transaction fails, the transactionterminates per step 1805.

It should be noted that the order in which the conditions are checkedneed not follow the order of steps 1806-1815.

At this point, right specific steps are now performed and arerepresented here as step 1816. The right specific steps are described ingreater detail below.

The common closing transaction steps are now performed. Each of theclosing transaction steps are performed by the server after a successfulcompletion of a transaction. Referring back to FIG. 18, the copies inuse value for the requested right is decremented by the number of copiesinvolved in the transaction, step 1817. Next, if the right had a meteredusage fee specification, the server subtracts the elapsed time from theRemaining-Use-Time associated with the right for every part involved inthe transaction, step 1818. Finally, if there are fee specificationsassociated with the right, the server initiates End-Charge financialtransaction to confirm billing, step 1819.

Transmission Protocol

An important area to consider is the transmission of the digital workfrom the server to the requester. The transmission protocol describedherein refers to events occurring after a valid session has beencreated. The transmission protocol must handle the case of disruption inthe communications between the repositories. It is assumed thatinterference such as injecting noise on the communication channel can bedetected by the integrity checks (e.g., parity, checksum, etc.) that arebuilt into the transport protocol and are not discussed in detailherein.

The underlying goal in the transmission protocol is to preclude certainfailure modes, such as malicious or accidental interference on thecommunications channel. Suppose, for example, that a user pulls a cardwith the credit server at a specific time near the end of a transaction.There should not be a vulnerable time at which “pulling the card” causesthe repositories to fail to correctly account for the number of copiesof the work that have been created. Restated, there should be no time atwhich a party can break a connection as a means to avoid payment afterusing a digital work.

If a transaction is interrupted (and fails), both repositories restorethe digital works and accounts to their state prior to the failure,modulo records of the failure itself.

FIG. 19 is a state diagram showing steps in the process of transmittinginformation during a transaction. Each box represents a state of arepository in either the server mode (above the central dotted line1901) or in the requester mode (below the dotted line 1901). Solidarrows stand for transitions between states. Dashed arrows stand formessage communications between the repositories. A dashed message arrowpointing to a solid transition arrow is interpreted as meaning that thetransition takes place when the message is received. Unlabeledtransition arrows take place unconditionally. Other labels on statetransition arrows describe conditions that trigger the transition.

Referring now to FIG. 19, the server is initially in a state 1902 wherea new transaction is initiated via start message 1903. This messageincludes transaction information including a transaction identifier anda count of the blocks of data to be transferred. The requester,initially in a wait state 1904 then enters a data wait state 1905.

The server enters a data transmit state 1906 and transmits a block ofdata 1907 and then enters a wait for acknowledgement state 1908. As thedata is received, the requesters enters a data receive state 1909 andwhen the data blocks is completely received it enters an acknowledgementstate 1910 and transmits an Acknowledgement message 1911 to the server.

If there are more blocks to send, the server waits until receiving anAcknowledgement message from the requester. When an Acknowledgementmessage is received it sends the next block to the requester and againwaits for acknowledgement. The requester also repeats the same cycle ofstates.

If the server detects a communications failure before sending the lastblock, it enters a cancellation state 1912 wherein the transaction iscancelled. Similarly, if the requester detects a communications failurebefore receiving the last block it enters a cancellation state 1913.

If there are no more blocks to send, the server commits to thetransaction and waits for the final Acknowledgement in state 1914. Ifthere is a communications failure before the server receives the finalAcknowledgement message, it still commits to the transaction butincludes a report about the event to its credit server in state 1915.This report serves two purposes. It will help legitimize any claims by auser of having been billed for receiving digital works that were notcompletely received. Also it helps to identify repositories andcommunications lines that have suspicious patterns of use andinterruption. The server then enters its completion state

On the requester side, when there are no more blocks to receive, therequester commits to the transaction in state 1917. If the requesterdetects a communications failure at this state, it reports the failureto its credit server in state 1918, but still commits to thetransaction. When it has committed, it sends an acknowledgement messageto the server. The server then enters its completion state 1919.

The key property is that both the server and the requester cancel atransaction if it is interrupted before all of the data blocks aredelivered, and commits to it if all of the data blocks have beendelivered.

There is a possibility that the server will have sent all of the datablocks (and committed) but the requester will not have received all ofthem and will cancel the transaction. In this case, both repositorieswill presumably detect a communications failure and report it to theircredit server. This case will probably be rare since it depends on veryprecise timing of the communications failure. The only consequence willbe that the user at the requester repository may want to request arefund from the credit services—and the case for that refund will bedocumented by reports by both repositories.

To prevent loss of data, the server should not delete any transferreddigital work until receiving the final acknowledgement from therequester. But it also should not use the file. A well known way to dealwith this situation is called “two-phase commit” or 2PC.

Two-phase commit works as follows. The first phase works the same as themethod described above. The server sends all of the data to therequester. Both repositories mark the transaction (and appropriatefiles) as uncommitted. The server sends a ready-to-commit message to therequester. The requester sends back an acknowledgement. The server thencommits and sends the requester a commit message. When the requesterreceives the commit message, it commits the file.

If there is a communication failure or other crash, the requester mustcheck back with the server to determine the status of the transaction.The server has the last word on this. The requester may have receivedall of the data, but if it did not get the final message, it has notcommitted. The server can go ahead and delete files (except fortransaction records) once it commits, since the files are known to havebeen fully transmitted before starting the 2PC cycle.

There are variations known in the art which can be used to achieve thesame effect. For example, the server could use an additional level ofencryption when transmitting a work to a client. Only after the clientsends a message acknowledging receipt does it send the key. The clientthen agrees to pay for the digital work. The point of this variation isthat it provides a clear audit trail that the client received the work.For trusted systems, however, this variation adds a level of encryptionfor no real gain in accountability.

The transactions for specific usage rights are now discussed.

The Copy Transaction

A Copy transaction is a request to make one or more independent copiesof the work with the same or lesser usage rights. Copy differs from theextraction right discussed later in that it refers to entire digitalworks or entire folders containing digital works. A copy operationcannot be used to remove a portion of a digital work.

The requester sends the server a message to initiate the CopyTransaction. This message indicates the work to be copied, the versionof the copy right to be used for the transaction, the destinationaddress information (location in a folder) for placing the work, thefile data for the work (including its size), and the number of copiesrequested.

The repositories perform the common opening transaction steps.

The server transmits the requested contents and data to the clientaccording to the transmission protocol. If a Next-Set-Of-Rights has beenprovided in the version of the right, those rights are transmitted asthe rights for the work. Otherwise, the rights of the original aretransmitted. In any event, the Copy-Count field for the copy of thedigital work being sent right is set to the number-of-copies requested.

The requester records the work contents, data, and usage rights andstores the work. It records the date and time that the copy was made inthe properties of the digital work.

The repositories perform the common closing transaction steps.

The Transfer Transaction

A Transfer transaction is a request to move copies of the work with thesame or lesser usage rights to another repository. In contrast with acopy transaction, this results in removing the work copies from theserver.

The requester sends the server a message to initiate the TransferTransaction. This message indicates the work to be transferred, theversion of the transfer right to be used in the transaction, thedestination address information for placing the work, the file data forthe work, and the number of copies involved.

The repositories perform the common opening transaction steps.

The server transmits the requested contents and data to the requesteraccording to the transmission protocol. If a Next-Set-Of-Rights has beenprovided, those rights are transmitted as the rights for the work.Otherwise, the rights of the original are transmitted. In either case,the Copy-Count field for the transmitted rights is set to thenumber-of-copies requested.

The requester records the work contents, data, and usage rights andstores the work.

The server decrements its copy count by the number of copies involved inthe transaction.

The repositories perform the common closing transaction steps.

If the number of copies remaining in the server is now zero, it erasesthe digital work from its memory.

The Loan Transaction

A loan transaction is a mechanism for loaning copies of a digital work.The maximum duration of the loan is determined by an internal parameterof the digital work. Works are automatically returned after apredetermined time period.

The requester sends the server a message to initiate the TransferTransaction. This message indicates the work to be loaned, the versionof the loan right to be used in the transaction, the destination addressinformation for placing the work, the number of copies involved, thefile data for the work, and the period of the loan.

The server checks the validity of the requested loan period, and endswith an error if the period is not valid. Loans for a loaned copy cannotextend beyond the period of the original loan to the server.

The repositories perform the common opening transaction steps.

The server transmits the requested contents and data to the requester.

If a Next-Set-Of-Rights has been provided, those rights are transmittedas the rights for the work. Otherwise, the rights of the original aretransmitted, as modified to reflect the loan period.

The requester records the digital work contents, data, usage rights, andloan period and stores the work.

The server updates the usage rights information in the digital work toreflect the number of copies loaned out.

The repositories perform the common closing transaction steps.

The server updates the usage rights data for the digital work. This maypreclude use of the work until it is returned from the loan. The user onthe requester platform can now use the transferred copies of the digitalwork. A user accessing the original repository cannot use the digitalwork, unless there are copies remaining. What happens next depends onthe order of events in time.

Case 1. If the time of the loan period is not yet exhausted and therequester sends the repository a Return message.

The return message includes the requester identification, and thetransaction ID.

The server decrements the copies-in-use field by the number of copiesthat were returned. (If the number of digital works returned is greaterthan the number actually borrowed, this is treated as an error.) Thisstep may now make the work available at the server for other users.

The requester deactivates its copies and removes the contents from itsmemory.

Case 2. If the time of the loan period is exhausted and the requesterhas not yet sent a Return message.

The server decrements the copies-in-use field by the number digitalworks that were borrowed.

The requester automatically deactivates its copies of the digital work.It terminates all current uses and erases the digital work copies frommemory. One question is why a requester would ever return a work earlierthan the period of the loan, since it would be returned automaticallyanyway. One reason for early return is that there may be a metered feewhich determines the cost of the loan. Returning early may reduce thatfee.

The Play Transaction

A play transaction is a request to use the contents of a work.Typically, to “play” a work is to send the digital work through somekind of transducer, such as a speaker or a display device. The requestimplies the intention that the contents will not be communicateddigitally to any other system. For example, they will not be sent to aprinter, recorded on any digital medium, retained after the transactionor sent to another repository.

This term “play” is natural for examples like playing music, playing amovie, or playing a video game. The general form of play means that a“player” is used to use the digital work. However, the term play coversall media and kinds of recordings. Thus one would “play” a digital work,meaning, to render it for reading, or play a computer program, meaningto execute it. For a digital ticket the player would be a digital ticketagent.

The requester sends the server a message to initiate the playtransaction. This message indicates the work to be played, the versionof the play right to be used in the transaction, the identity of theplayer being used, and the file data for the work.

The server checks the validity of the player identification and thecompatibility of the player identification with the player specificationin the right. It ends with an error if these are not satisfactory.

The repositories perform the common opening transaction steps.

The server and requester read and write the blocks of data as requestedby the player according to the transmission protocol. The requesterplays the work contents, using the player.

When the player is finished, the player and the requester remove thecontents from their memory.

The repositories perform the common closing transaction steps.

The Print Transaction

A Print transaction is a request to obtain the contents of a work forthe purpose of rendering them on a “printer.” We use the term “printer”to include the common case of writing with ink on paper. However, thekey aspect of “printing” in our use of the term is that it makes a copyof the digital work in a place outside of the protection of usagerights. As with all rights, this may require particular authorizationcertificates.

Once a digital work is printed, the publisher and user are bound bywhatever copyright laws are in effect. However, printing moves thecontents outside the control of repositories. For example, absent anyother enforcement mechanisms, once a digital work is printed on paper,it can be copied on ordinary photocopying machines without interventionby a repository to collect usage fees. If the printer to a digital diskis permitted, then that digital copy is outside of the control of usagerights. Both the creator and the user know this, although the creatordoes not necessarily give tacit consent to such copying, which mayviolate copyright laws.

The requester sends the server a message to initiate a Printtransaction. This message indicates the work to be played, the identityof the printer being used, the file data for the work, and the number ofcopies in the request.

The server checks the validity of the printer identification and thecompatibility of the printer identification with the printerspecification in the right. It ends with an error if these are notsatisfactory.

The repositories perform the common opening transaction steps.

The server transmits blocks of data according to the transmissionprotocol.

The requester prints the work contents, using the printer.

When the printer is finished, the printer and the requester remove thecontents from their memory.

The repositories perform the common closing transaction steps.

The Backup Transaction

A Backup transaction is a request to make a backup copy of a digitalwork, as a protection against media failure. In the context ofrepositories, secure backup copies differ from other copies in threeways: (1) they are made under the control of a Backup transaction ratherthan a Copy transaction, (2) they do not count as regular copies, and(3) they are not usable as regular copies. Generally, backup copies areencrypted.

Although backup copies may be transferred or copied, depending on theirassigned rights, the only way to make them useful for playing, printingor embedding is to restore them.

The output of a Backup operation is both an encrypted data file thatcontains the contents and description of a work, and a restoration filewith an encryption key for restoring the encrypted contents. In manycases, the encrypted data file would have rights for “printing” it to adisk outside of the protection system, relying just on its encryptionfor security. Such files could be stored anywhere that was physicallysafe and convenient. The restoration file would be held in therepository. This file is necessary for the restoration of a backup copy.It may have rights for transfer between repositories.

The requester sends the server a message to initiate a backuptransaction. This message indicates the work to be backed up, theversion of the backup right to be used in the transaction, thedestination address information for placing the backup copy, the filedata for the work.

The repositories perform the common opening transaction steps.

The server transmits the requested contents and data to the requester.If a Next-Set-Of-Rights has been provided, those rights are transmittedas the rights for the work. Otherwise, a set of default rights forbackup files of the original are transmitted by the server.

The requester records the work contents, data, and usage rights. It thencreates a one-time key and encrypts the contents file. It saves the keyinformation in a restoration file.

The repositories perform the common closing transaction steps.

In some cases, it is convenient to be able to archive the large,encrypted contents file to secure offline storage, such as amagneto-optical storage system or magnetic tape. This creation of anon-repository archive file is as secure as the encryption process. Suchnon-repository archive storage is considered a form of “printing” and iscontrolled by a print right with a specified “archive-printer.” Anarchive-printer device is programmed to save the encrypted contents file(but not the description file) offline in such a way that it can beretrieved.

The Restore Transaction

A Restore transaction is a request to convert an encrypted backup copyof a digital work into a usable copy. A restore operation is intended tobe used to compensate for catastrophic media failure. Like all usagerights, restoration rights can include fees and access tests includingauthorization checks.

The requester sends the server a message to initiate a Restoretransaction. This message indicates the work to be restored, the versionof the restore right for the transaction, the destination addressinformation for placing the work, and the file data for the work.

The server verifies that the contents file is available (i.e. a digitalwork corresponding to the request has been backed-up.) If it is not, itends the transaction with an error.

The repositories perform the common opening transaction steps.

The server retrieves the key from the restoration file. It decrypts thework contents, data, and usage rights.

The server transmits the requested contents and data to the requesteraccording to the transmission protocol. If a Next-Set-Of-Rights has beenprovided, those rights are transmitted as the rights for the work.Otherwise, a set of default rights for backup files of the original aretransmitted by the server.

The requester stores the digital work.

The repositories perform the common closing transaction steps.

The Delete Transaction

A Delete transaction deletes a digital work or a number of copies of adigital work from a repository. Practically all digital works would havedelete rights.

The requester sends the server a message to initiate a deletetransaction. This message indicates the work to be deleted, the versionof the delete right for the transaction.

The repositories perform the common opening transaction steps.

The server deletes the file, erasing it from the file system.

The repositories perform the common closing transaction steps.

The Directory Transaction

A Directory transaction is a request for information about folders,digital works, and their parts. This amounts to roughly the same idea asprotection codes in a conventional file system like TENEX, except thatit is generalized to the full power of the access specifications of theusage rights language.

The Directory transaction has the important role of passing alongdescriptions of the rights and fees associated with a digital work. Whena user wants to exercise a right, the user interface of his repositoryimplicitly makes a directory request to determine the versions of theright that are available. Typically these are presented to the user—suchas with different choices of billing for exercising a right. Thus, manydirectory transactions are invisible to the user and are exercised aspart of the normal process of exercising all rights.

The requester sends the server a message to initiate a Directorytransaction. This message indicates the file or folder that is the rootof the directory request and the version of the directory right used forthe transaction.

The server verifies that the information is accessible to the requester.

In particular, it does not return the names of any files that have aHIDE-NAME status in their directory specifications, and it does notreturn the parts of any folders or files that have HIDE-PARTS in theirspecification. If the information is not accessible, the server ends thetransaction with an error.

The repositories perform the common opening transaction steps.

The server sends the requested data to the requester according to thetransmission protocol.

The requester records the data.

The repositories perform the common closing transaction steps.

The Folder Transaction

A Folder transaction is a request to create or rename a folder, or tomove a work between folders. Together with Directory rights, Folderrights control the degree to which organization of a repository can beaccessed or modified from another repository.

The requester sends the server a message to initiate a Foldertransaction. This message indicates the folder that is the root of thefolder request, the version of the folder right for the transaction, anoperation, and data. The operation can be one of create, rename, andmove file. The data are the specifications required for the operation,such as a specification of a folder or digital work and a name.

The repositories perform the common opening transaction steps.

The server performs the requested operation—creating a folder, renaminga folder, or moving a work between folders.

The repositories perform the common closing transaction steps.

The Extract Transaction

A extract transaction is a request to copy a part of a digital work andto create a new work containing it. The extraction operation differsfrom copying in that it can be used to separate a part of a digital workfrom d-blocks or shells that place additional restrictions or fees onit. The extraction operation differs from the edit operation in that itdoes not change the contents of a work, only its embedding in d-blocks.Extraction creates a new digital work.

The requester sends the server a message to initiate an Extracttransaction. This message indicates the part of the work to beextracted, the version of the extract right to be used in thetransaction, the destination address information for placing the part asa new work, the file data for the work, and the number of copiesinvolved.

The repositories perform the common opening transaction steps.

The server transmits the requested contents and data to the requesteraccording to the transmission protocol. If a Next-Set-Of-Rights has beenprovided, those rights are transmitted as the rights for the new work.Otherwise, the rights of the original are transmitted. The Copy-Countfield for this right is set to the number-of-copies requested.

The requester records the contents, data, and usage rights and storesthe work. It records the date and time that new work was made in theproperties of the work.

The repositories perform the common closing transaction steps.

The Embed Transaction

An embed transaction is a request to make a digital work become a partof another digital work or to add a shell d-block to enable the addingof fees by a distributor of the work.

The requester sends the server a message to initiate an Embedtransaction. This message indicates the work to be embedded, the versionof the embed right to be used in the transaction, the destinationaddress information for placing the part as a work, the file data forthe work, and the number of copies involved.

The server checks the control specifications for all of the rights inthe part and the destination. If they are incompatible, the server endsthe transaction with an error.

The repositories perform the common opening transaction steps.

The server transmits the requested contents and data to the requesteraccording to the transmission protocol. If a Next-Set-Of-Rights has beenprovided, those rights are transmitted as the rights for the new work.Otherwise, the rights of the original are transmitted. The Copy-Countfield for this right is set to the number-of-copies requested.

The requester records the contents, data, and usage rights and embedsthe work in the destination file.

The repositories perform the common closing transaction steps.

The Edit Transaction

An Edit transaction is a request to make a new digital work by copying,selecting and modifying portions of an existing digital work. Thisoperation can actually change the contents of a digital work. The kindsof changes that are permitted depend on the process being used. Like theextraction operation, edit operates on portions of a digital work. Incontrast with the extract operation, edit does not effect the rights orlocation of the work. It only changes the contents. The kinds of changespermitted are determined by the type specification of the processorspecified in the rights. In the currently preferred embodiment, an edittransaction changes the work itself and does not make a new work.However, it would be a reasonable variation to cause a new copy of thework to be made.

The requester sends the server a message to initiate an Edittransaction. This message indicates the work to be edited, the versionof the edit right to be used in the transaction, the file data for thework (including its size), the process-ID for the process, and thenumber of copies involved.

The server checks the compatibility of the process-ID to be used by therequester against any process-ID specification in the right. If they areincompatible, it ends the transaction with an error.

The repositories perform the common opening transaction steps.

The requester uses the process to change the contents of the digitalwork as desired. (For example, it can select and duplicate parts of it;combine it with other information; or compute functions based on theinformation. This can amount to editing text, music, or pictures ortaking whatever other steps are useful in creating a derivative work.)

The repositories perform the common closing transaction steps.

The edit transaction is used to cover a wide range of kinds of works.The category describes a process that takes as its input any portion ofa digital work and then modifies the input in some way. For example, fortext, a process for editing the text would require edit rights. Aprocess for “summarizing” or counting words in the text would also beconsidered editing. For a music file, processing could involve changingthe pitch or tempo, or adding reverberations, or any other audio effect.For digital video works, anything which alters the image would requireedit rights. Examples would be colorizing, scaling, extracting stillphotos, selecting and combining frames into story boards, sharpeningwith signal processing, and so on.

Some creators may want to protect the authenticity of their works bylimiting the kinds of processes that can be performed on them. If thereare no edit rights, then no processing is allowed at all. A processoridentifier can be included to specify what kind of process is allowed.If no process identifier is specified, then arbitrary processors can beused. For an example of a specific process, a photographer may want toallow use of his photograph but may not want it to be colorized. Amusician may want to allow extraction of portions of his work but notchanging of the tonality.

Authorization Transactions

There are many ways that authorization transactions can be defined. Inthe following, our preferred way is to simply define them in terms ofother transactions that we already need for repositories. Thus, it isconvenient sometimes to speak of “authorization transactions,” but theyare actually made up of other transactions that repositories alreadyhave.

A usage right can specify an authorization-ID, which identifies anauthorization object (a digital work in a file of a standard format)that the repository must have and which it must process. Theauthorization is given to the generic authorization (or ticket) serverof the repository which begins to interpret the authorization.

As described earlier, the authorization contains a server identifier,which may just be the generic authorization server or it may be anotherserver. When a remote authorization server is required, it must containa digital address. It may also contain a digital certificate.

If a remote authorization server is required, then the authorizationprocess first performs the following steps:

The generic authorization server attempts to set up the communicationschannel. (If the channel cannot be set up, then authorization fails withan error.)

When the channel is set up, it performs a registration process with theremote repository. (If registration fails, then the authorization failswith an error.)

When registration is complete, the generic authorization server invokesa “Play” transaction with the remote repository, supplying theauthorization document as the digital work to be played, and the remoteauthorization server (a program) as the “player.” (If the player cannotbe found or has some other error, then the authorization fails with anerror.)

The authorization server then “plays” the authorization. This involvesdecrypting it using either the public key of the master repository thatissued the certificate or the session key from the repository thattransmitted it. The authorization server then performs various tests.These tests vary according to the authorization server. They includesuch steps as checking issue and validity dates of the authorization andchecking any hot-lists of known invalid authorizations. Theauthorization server may require carrying out any other transactions onthe repository as well, such as checking directories, getting someperson to supply a password, or playing some other digital work. It mayalso invoke some special process for checking information aboutlocations or recent events. The “script” for such steps is containedwithin the authorization server.

If all of the required steps are completed satisfactorily, theauthorization server completes the transaction normally, signaling thatauthorization is granted.

The Install Transaction

An Install transaction is a request to install a digital work asrunnable software on a repository. In a typical case, the requesterrepository is a rendering repository and the software would be a newkind or new version of a player. Also in a typical case, the softwarewould be copied to file system of the requester repository before it isinstalled.

The requester sends the server an Install message. This messageindicates the work to be installed, the version of the Install rightbeing invoked, and the file data for the work (including its size).

The repositories perform the common opening transaction steps.

The requester extracts a copy of the digital certificate for thesoftware. If the certificate cannot be found or the master repositoryfor the certificate is not known to the requester, the transaction endswith an error.

The requester decrypts the digital certificate using the public key ofthe master repository, recording the identity of the supplier andcreator, a key for decrypting the software, the compatibilityinformation, and a tamper-checking code. (This step certifies thesoftware.)

The requester decrypts the software using the key from the certificateand computes a check code on it using a 1-way hash function. If thecheck-code does not match the tamper-checking code from the certificate,the installation transaction ends with an error. (This step assures thatthe contents of the software, including the various scripts, have notbeen tampered with.)

The requester retrieves the instructions in the compatibility-checkingscript and follows them. If the software is not compatible with therepository, the installation transaction ends with an error. (This stepchecks platform compatibility.)

The requester retrieves the instructions in the installation script andfollows them. If there is an error in this process (such as insufficientresources), then the transaction ends with an error. Note that theinstallation process puts the runnable software in a place in therepository where it is no longer accessible as a work for exercising anyusage rights other than the execution of the software as part ofrepository operations in carrying out other transactions.

The repositories perform the common closing transaction steps.

The Uninstall Transaction

An Uninstall transaction is a request to remove software from arepository. Since uncontrolled or incorrect removal of software from arepository could compromise its behavioral integrity, this step iscontrolled.

The requester sends the server an Uninstall message. This messageindicates the work to be uninstalled, the version of the Uninstall rightbeing invoked, and the file data for the work (including its size).

The repositories perform the common opening transaction steps.

The requester extracts a copy of the digital certificate for thesoftware. If the certificate cannot be found or the master repositoryfor the certificate is not known to the requester, the transaction endswith an error.

The requester checks whether the software is installed. If the softwareis not installed, the transaction ends with an error.

The requester decrypts the digital certificate using the public key ofthe master repository, recording the identity of the supplier andcreator, a key for decrypting the software, the compatibilityinformation, and a tamper-checking code. (This step authenticates thecertification of the software, including the script for uninstallingit.)

The requester decrypts the software using the key from the certificateand computes a check code on it using a 1-way hash function. If thecheck-code does not match the tamper-checking code from the certificate,the installation transaction ends with an error. (This step assures thatthe contents of the software, including the various scripts, have notbeen tampered with.)

The requester retrieves the instructions in the uninstallation scriptand follows them. If there is an error in this process (such asinsufficient resources), then the transaction ends with an error.

The repositories perform the common closing transaction steps.

Distribution and Use Scenarios

To appreciate the robustness and flexibility of the present invention,various distribution and use scenarios for digital works are illustratedbelow. These scenarios are meant to be exemplary rather than exhaustive.

Consumers as Unpaid Distributors

In this scenario, a creator distributes copies of his works to variousconsumers. Each consumer is a potential distributor of the work. If theconsumer copies the digital work (usually for a third party), a fee iscollected and automatically paid to the creator.

This scenario is a new twist for digital works. It depends on the ideathat “manufacturing” is just copying and is essentially free. It alsoassumes that the consumers as distributors do not require a fee fortheir time and effort in distributing the work.

This scenario is performed as follows:

A creator creates a digital work. He grants a Copy right with fees paidback to himself. If he does not grant an Embed right, then consumerscannot use the mechanism to act as distributors to cause fees to be paidto themselves on future copies. Of course, they could negotiate sidedeals or trades to transfer money on their own, outside of the system.

Paid Distributors

In another scenario, every time a copy of a digital work is sold a feeis paid to the creator and also to the immediate distributor.

This scenario does not give special status to any particulardistributor. Anyone who sells a document has the right to add a fee tothe sale price. The fee for sale could be established by the consumer.It could also be a fixed nominal amount that is contributed to theaccount of some charity.

This scenario is performed as follows:

A creator creates a digital work. He grants a Copy right with fees to bepaid back to himself. He grants an Embed right, so that anyone can addshells to have fees paid to themselves.

A distributor embeds the work in a shell, with fees specified to be paidback to himself If the distributor is content to receive fees only forcopies that he sells himself, he grants an Extract right on the shell.

When a consumer buys a copy from the distributor, fees are paid both tothe distributor and to the creator. If he chooses, the consumer canextract the work from the distributor's shell. He cannot extract it fromthe creator's shell. He can add his own shell with fees to be paid tohimself.

Licensed Distribution

In this scenario, a creator wants to protect the reputation and value ofhis work by making certain requirements on its distributors. He issueslicenses to distributors that satisfy the requirements, and in turn,promises to reward their efforts by assuring that the work will not bedistributed over competing channels. The distributors incur expenses forselecting the digital work, explaining it to buyers, promoting its sale,and possibly for the license itself. The distributor obtains the rightto enclose the digital work in a shell, whose function is to permit theattachment of usage fees to be paid to the distributor in addition tothe fees to be paid to the creator.

This differs from the previous scenario in that it precludes the typicalcopy owner from functioning as a distributor, since the consumer lacks alicense to copy the document. Thus, a consumer cannot make copies, evenfor free. All copies must come initially from authorized distributors.This version makes it possible to hold distributors accountable in someway for the sales and support of the work, by controlling thedistribution of certificates that enable distributors to legitimatelycharge fees and copy owners to make copies. Since licenses arethemselves digital works, the same mechanisms give the creators controlover distributors by charging for licenses and putting time limits ontheir validity.

This scenario is performed as follows:

A creator purchases a digital distribution license that he will hand outto his distributors. He puts access requirements (such as a personallicense) on the Copy and Transfer rights on the distribution license sothat only he can copy or transfer it.

The creator also creates a digital work. He grants an Embed right and aCopy right, both of which require the distribution license to beexercised. He grants a Play right so that the work can be played byanyone. He may optionally add a Transfer or Loan right, so that endconsumers can do some non-commercial exchange of the work among friends.

A distributor obtains the distribution license and a number of copies ofthe work. He makes copies for his customers, using his distributionlicense.

A customer buys and uses the work. He cannot make new copies because helacks a distribution license.

Super Distributors

This is a variation on the previous scenarios. A distributor can sell toanyone and anyone can sell additional copies, resulting in fees beingpaid back to the creator. However, only licensed distributors can addfees to be paid to themselves.

This scenario gives distributors the right to add fees to cover theirown advertising and promotional costs, without making them be the solesuppliers. Their customers can also make copies, thus broadening thechannel without diminishing their revenues. This is because distributorscollect fees from copies of any copies that they originally sold. Onlydistributors can add fees.

This scenario is performed similarly to the previous ones. There are twokey differences. (1) The creator only grants Embed rights for people whohave a Distribution license. This is done by putting a requirement for adistributor's license on the Embed right. Consequently, non-distributorscannot add their own fees. (2) The Distributor does not grant Extractrights, so that consumers cannot avoid paying fees to the Distributor ifthey make subsequent copies. Consequently, all subsequent copies resultin fees paid to the Distributor and the Creator.

1-Level Distribution Fees

In this scenario, a distributor gets a fee for any copy he sellsdirectly. However, if one of his customers sells further copies, he getsno further fee for those copies.

This scenario pays a distributor only for use of copies that he actuallysold.

This scenario is performed similarly to the previous ones. The keyfeature is that the distributor creates a shell which specifies fees tobe paid to him. He puts Extract rights on the shell. When a consumerbuys the work, he can extract away the distributor's shell. Copies madeafter that will not require fees to be paid to the distributor.

Distribution Trees

In another scenario, distributors sell to other distributors and feesare collected at each level. Every copy sold by any distributor—evenseveral d-blocks down in the chain—results in a fee being paid back toall of the previous distributors.

This scenario is like a chain letter or value chain. Every contributoror distributor along the way obtains fees, and is thereby encouraged topromote the sale of copies of the digital work.

This scenario is performed similarly to the previous ones. The keyfeature is that the distributor creates a shell which specifies fees tobe paid to him. He does not grant Extract rights on the shell.Consequently, all future copies that are made will result in fees paidto him.

Weighted Distribution Trees

In this scenario, distributors make money according to a distributiontree. The fee that they make depends on various parameters, such as timesince their sale or the number of subsequent distributors.

This is a generalized version of the Distribution Tree scenario, in thatit tries to vary the fee to account for the significance of the role ofthe distributor.

This scenario is similar to the previous one. The difference is that thefee specification on the distributor's shell has provisions for changesin prices. For example, there could be a fee schedule so that copiesmade after the passage of time will require lower fees to be paid to thedistributor. Alternatively, the distributor could employ a “best-price”billing option, using any algorithm he chooses to determine the fee upto the maximum specified in the shell.

Fees for Reuse

In this scenario, a first creator creates a work. It is distributed by afirst distributor and purchased by a second creator. The second creatorextracts a portion of the work and embeds in it a new work distributedby a second distributor. A consumer buys the new work from the seconddistributor. The first creator receives fees from every transaction; thefirst distributor receives fees only for his sale; the second creatorand second distributor receive fees for the final sale.

This scenario shows how that flexible automatic arrangements can be setup to create automatic charging systems that mirror current practice.This scenario is analogous to when an author pays a fee to reuse afigure in some paper. In the most common case, a fee is paid to thecreator or publisher, but not to the bookstore that sold the book.

The mechanisms for derived works are the same as those for distribution.

Limited Reuse

In this scenario, several first creators create works. A second creatormakes a selection of these, publishing a collection made up of the partstogether with some new interstitial material. (For example, the digitalwork could be a selection of music or a selection of readings.) Thesecond creator wants to continue to allow some of the selected works tobe extractable, but not the interstitial material.

This scenario deals with fine grained control of the rights and fees forreuse.

This scenario is performed as follows:

The first creators create their original works. If they grant extractionand embedding rights, then the second creator can include them in alarger collected work. The second creator creates the interstitialmaterial. He does grant an Extract right on the interstitial material.He grants Extract rights on a subset of the reused material. A consumerof the collection can only extract portions that have that right. Feesare automatically collected for all parts of the collection.

Commercial Libraries

Commercial libraries buy works with the right to loan. They limit theloan period and charge their own fees for use. This scenario deals withfees for loaning rather than fees for making copies. The fees arecollected by the same automatic mechanisms.

The mechanisms are the same as previous scenarios except that the feesare associated with the Loan usage right rather than the Copy usageright.

Demo Versions

A creator believes that if people try his work that they will want tobuy it or use it. Consumers of his work can copy the work for free, andplay (or execute) a limited version of the work for free, and can playor use the full featured version for a fee. This scenario deals withfees for loaning rather than fees for making copies. The fees arecollected by the same automatic mechanisms.

This scenario is performed as follows:

The creator creates a digital work and grants various rights and fees.The creator grants Copy and Embed rights without a fee, in order toensure widespread distribution of the work. Another of the rights is alimited play right with little or no fee attached. For example, thisright may be for playing only a portion of the work. The play right canhave various restrictions on its use. It could have a ticket that limitsthe number of times it is used. It could have internal restrictions thatlimit its functionality. It could have time restrictions that invalidatethe right after a period of time or a period of use. Different feescould be associated with other versions of the Play right.

Upgrading a Digital Work with a Vendor

A consumer buys a digital work together with an agreement that he canupgrade to a new version at a later date for a modest fee, much lessthan the usual purchase price. When the new version becomes available,he goes to a qualified vendor to make the transaction.

This scenario deals with a common situation in computer software. Itshows how a purchase may include future “rights.” Two important featuresof the scenario are that the transaction must take place at a qualifiedvendor, and that the transaction can be done only once per copy of thedigital work purchased.

This scenario is performed as follows:

The creator creates a digital work, an upgrade ticket, and adistribution license. The upgrade ticket uses the a generic ticket agentthat comes with repositories. As usual, the distribution license doesnot have Copy or Transfer rights. He distributes a bundled copies of thework and the ticket to his distributors as well as distributionlicenses.

The distributor sells the old bundled work and ticket to customers.

The customer extracts the work and the ticket. He uses the workaccording to the agreements until the new version becomes available.

When the new work is ready, the creator gives it to distributors. Thenew work has a free right to copy from a distributor if a ticket isavailable.

The consumer goes to distributors and arranges to copy the work. Thetransaction offers the ticket. The distributor's repository punches theticket and copies the new version to the consumer's repository.

The consumer can now use the new version of the work.

Distributed Upgrading of Digital Works

A consumer buys a digital work together with an agreement that he canupgrade to a new version at a later date for a modest fee, much lessthan the usual purchase price. When the new version becomes available,he goes to anyone who has the upgraded version and makes thetransaction.

This scenario is like the previous one in that the transaction can onlybe done once per copy of the digital work purchased, but the transactioncan be accomplished without the need to connect to a licensed vendor.

This scenario is similar to the previous one except that the Copy righton the new work does not require a distribution license. The consumercan upgrade from any repository having the new version. He cannotupgrade more than once because the ticket cannot work after it has beenpunched. If desired, the repository can record the upgrade transactionby posting a zero cost bill to alert the creator that the upgrade hastaken place.

Limited Printing

A consumer buys a digital work and wants to make a few ephemeral copies.For example, he may want to print out a paper copy of part of a digitalnewspaper, or he may want to make a (first generation) analog cassettetape for playing in his car. He buys the digital work together with aticket required for printing rights.

This scenario is like the common practice of people making cassettetapes to play in their car. If a publisher permits the making ofcassette tapes, there is nothing to prevent a consumer from furthercopying the tapes. However, since the tapes are “analog copies,” thereis a noticeable quality loss with subsequent generations. The newcontribution of the present invention is the use of tickets in theaccess controls for the making of the analog copies.

This scenario is performed as follows:

The creator sells a work together with limited printing rights. Theprinting rights specify the kind of printer (e.g., a kind of cassetterecorder or a kind of desktop paper printer) and also the kind of ticketrequired. The creator either bundles a limited number of tickets orsells them separately. If the tickets use the generic ticket agent, theconsumer with the tickets can exercise the right at his convenience.

Demand Publishing

Professors in a business school want to put together course books ofreadings selected from scenario studies from various sources. Thebookstore wants to be able to print the books from digital masters,without negotiating for and waiting for approval of printing of each ofthe scenarios. The copyright holders of the scenarios want to be surethat they are paid for every copy of their work that is printed.

On many college campuses, the hassle of obtaining copy clearances in atimely way has greatly reduced the viability of preparing course books.Print shops have become much more cautious about copying works in theabsence of documented permission.

Demand Publishing is performed as follows: the creator sells a worktogether with printing rights for a fee. There can be rights to copy(distribute) the work between bookstore repositories, with or withoutfee. The printing rights specify the kind of printer. Whenever abookstore prints one of the works (either standalone or embedded in acollection), the fee is credited to the creator automatically. Todiscourage unauthorized copying of the print outs, it would be possiblefor the printer to print tracer messages discretely on the pagesidentifying the printing transaction, the copy number, and any otheridentifying information. The tracer information could be secretlyembedded in the text itself (encoded in the grey scale) or hidden insome other way.

Metered Use and Multiple Price Packages

A consumer does not know what music to purchase until he decides whetherhe likes it. He would like to be able to take it home and listen to it,and then decide whether to purchase. Furthermore, he would like theflexibility of paying less if he listens to it very infrequently.

This scenario just uses the capability of the approach to have multipleversions of a right on a digital work. Each version of the right has itsown billing scheme. In this scenario, the creator of the work can offerthe Copy right without fee, and defer billing to the exercise of thePlay right. One version of the play right would allow a limitedperformance without fee—a right to “demo”. Another version of the rightcould have a metered rate, of say $0.25 per hour of play. Anotherversion could have a fee of $15.00 for the first play, but no fee forfurther playing. When the consumer exercises a play right, he specifieswhich version of the right is being selected and is billed accordingly.

Fees for Font Usage

A designer of type fonts invests several months in the design of specialfonts. The most common way of obtaining revenue for this work is to sellcopies of the fonts to publishers for unlimited use over unlimitedperiods of time. A font designer would like to charge a rate thatreflects the amount that the font is used.

This scenario is performed as follows: the font designer creates a fontas a digital work. He creates versions of the Play right that billeither for metered use or “per-use”. Each version of the play rightwould require that the player (a print layout program) be of an approvedcategory. The font designer assigns appropriate fees to exercise theCopy right. When a publisher client wants to use a font, he includes itas input to a layout program, and is billed automatically for its use.In this way, a publisher who makes little use of a font pays less thanone who uses it a lot.

Rational Database Usage Charges

Online information retrieval services typically charge for access in away that most clients find unpredictable and uncorrelated to value orinformation use. The fee depends on which databases are open, dial-upconnect time, how long the searches require, and which articles areprinted out. There are no provisions for extracting articles orphotographs, no method for paying to reuse information in new works, nodistinction between having the terminal sit idly versus activelysearching for data, no distinction between reading articles on thescreen and doing nothing, and higher rates per search when thecentralized facility is busy and slow servicing other clients. Articlescan not be offloaded to the client's machine for off-site search andprinting. To offer such billing or the expanded services, the servicecompany would need a secure way to account for and bill for howinformation is used.

This scenario is performed as follows:

The information service bundles its database as files in a repository.The information services company assigns different fees for differentrights on the information files. For example, there could be a fee forcopying a search database or a source file and a different fee forprinting. These fees would be in addition to fees assigned by theoriginal creator for the services. The fees for using information wouldbe different for using them on the information service company'scomputers or the client's computers. This billing distinction would becontrolled by having different versions of the rights, where the versionfor use on the service company's computer requires a digital certificateheld locally. Fees for copying or printing files would be handled in theusual way, by assigning fees to exercising those rights. The distinctionbetween searching and viewing information would be made by havingdifferent “players” for the different functions. This distinction wouldbe maintained on the client's computers as well as the servicecomputers. Articles could be extracted for reuse under the control ofExtract and Embed rights. Thus, if a client extracts part of an articleor photograph, and then sells copies of a new digital work incorporatingit, fees could automatically be collected both by the informationservice and earlier creators and distributors of the digital work. Inthis way, the information retrieval service could both offer a widerselection of services and billing that more accurately reflects theclient's use of the information.

Print Spooling with Rights

In the simplest scenario, when a user wants to print a digital documenthe issues a print command to the user interface. If the document has theappropriate rights and the conditions are satisfied, the user agrees tothe fee and the document is printed. In other cases, the printer may beon a remote repository and it is convenient to spool the printing to alater time. This leads to several issues. The user requesting theprinting wants to be sure that he is not billed for the printing untilthe document is actually printed. Restated, if he is billed at the timethe print job is spooled but the job is canceled before printing isdone, he does not want to pay. Another issue is that when spooling ispermitted, there are now two times at which rights, conditions and feescould be checked: the time at which a print job is spooled and the timeat which a print is made. As with all usage rights, it is possible tohave rights that expire and to have rights whose fee depends on variousconditions. What is needed is a means to check rights and conditions atthe time that printing is actually done.

This scenario is performed as follows: A printing repository is arepository with the usual repository characteristics plus the hardwareand software to enable printing. Suppose that a user logs into a homerepository and wants to spool print jobs for a digital work at a remoteprinting repository. The user interface for this could treat this as arequest to “spool” prints. Underneath this “spooling” request, however,are standard rights and requests. To support such requests, the creatorof the work provides a Copy right, which can be used to copy the work toa printing repository. In the default case, this Copy right would haveno fees associated for making the copy. However, the Next-Set-Of-Rightsfor the copy would only include the Print rights, with the usual feesfor each variation of printing. This version of the Copy right could becalled the “print spooling” version of the Copy right. The user's “spoolrequest” is implemented as a Copy transaction to put a copy of the workon the printing repository, followed by Print transactions to create theprints of the work. In this way, the user is only billed for printingthat is actually done. Furthermore, the rights, conditions and fees forprinting the work are determined when the work is about to be printed.

Thus, a system for enforcing the usage rights of digital works isdisclosed. While the embodiments disclosed herein are preferred, it willbe appreciate from this teaching that various alternative,modifications, variations or improvements therein may be made by thoseskilled in the art, which are intended to be encompassed by thefollowing claims.

APPENDIX A Glossary

Authorization Repository:

A special type of repository which provides an authorization service. Anauthorization may be specified by a usage right. The authorization mustbe obtained before the right may be exercised.

Billing Clearinghouse:

A financial institution or the like whose purpose is to reconcilebilling information received from credit servers. The billingclearinghouse may generate bills to users or alternatively, credit anddebit accounts involved in the commercial transactions.

Billing Transactions:

The protocol used by which a repository reports billing information to acredit server.

Clearinghouse Transactions:

The protocol used between a credit server and a clearinghouse.

Composite Digital Work:

A digital work comprised of distinguishable parts. Each of thedistinguishable parts is itself a digital work which has usage rightsattached.

Content:

The digital information (i.e. raw bits) representing a digital work.

Copy Owner:

A term which refers to the party who owns a digital work stored in arepository. In the typical case, this party has purchased various rightsto the document for printing, viewing, transferring, or other specificuses.

Creator:

A term which refers to a party who produces a digital work.

Credit Server:

A device which collects and reports billing information for arepository. In many implementations, this could be built as part of arepository. It requires a means for periodically communicating with abilling clearinghouse.

Description Tree:

A structure which describes the location of content and the usage rightsand usage fees for a digital work. A description tree is comprised ofdescription blocks. Each description block corresponds to a digital workor to an interest (typically a revenue bearing interest) in a digitalwork.

Digital Work (Work):

Any encapsulated digital information. Such digital information mayrepresent music, a magazine or book, or a multimedia composition. Usagerights and fees are attached to the digital work.

Distributor:

A term which refers to a party who legitimately obtains a copy of adigital work and offers it for sale.

Identification (Digital) Certificate:

A signed digital message that attests to the identity of the possessor.Typically, digital certificates are encrypted in the private key of awell-known master repository.

Master Repository:

A special type of repository which issues identification certificatesand distributes lists of repositories whose integrity have beencompromised and which should be denied access to digital works (referredto as repository “hotlists”.)

Public Key Encryption:

An encryption technique used for secure transmission of messages on acommunication channel. Key pairs are used for the encryption anddecryption of messages. Typically one key is referred to as the publickey and the other is the private key. The keys are inverses of eachother from the perspective of encryption. Restated, a digital work thatis encrypted by one key in the pair can be decrypted only by the other.

Registration Transactions:

The protocol used between repositories to establish a trusted session.

Rendering Repository:

A special type of repository which is typically coupled to a renderingsystem. The rendering repository will typically be embodied within thesecure boundaries of a rendering system.

Rendering System:

The combination of a rendering repository and a rendering device.Examples of a rendering systems include printing systems, displaysystems, general purpose computer systems, video systems or audiosystems.

Repository:

Conceptually a set of functional specifications defining corefunctionality in the support of usage rights. A repository is a trustedsystem in that it maintains physical, communications and behavioralintegrity.

Requestor Mode:

A mode of a repository where it is requesting access to a digital work.

Revenue Owners:

A term which refers to the parties that maintain an interest incollecting fees for document use or who stand to lose revenue ifillegitimate copies of the digital work are made.

Server Mode:

A mode of a repository where it is processing an incoming request toaccess a digital work.

Shell Description Block:

A special type of description block designating an interest in a digitalwork, but which does not add content. This will typically be added by adistributor of a digital work to add their fees.

Transactions:

A term used to refer to the protocols by which repositories communicate.

Usage Fees:

A fee charged to a requester for access to a digital work. Usage feesare specified within the usage rights language.

Usage Rights:

A language for defining the manner in which a digital work may be usedor distributed, as well as any conditions on which use or distributionis premised.

Usage Transactions

A set of protocols by which repositories communicate in the exercise ofa usage rights. Each usage right has it's own transaction steps.

1. A method for controlling the number of times that a usage right associated with a digital work can be exercised, the method comprising: creating a digital work; determining a usage right for the digital work, the usage right specifying a digital ticket, the digital ticket indicating a number of times the usage right may be exercised; requesting access to the digital work including an identification of the usage right; determining the validity of the usage right based on a number of times the digital ticket has been used; granting or denying access to the digital work based on the result of the determining step; and updating the digital ticket if access to the digital work is granted.
 2. The method of claim 1, further comprising: creating the digital ticket with an indicator of the predetermined number; storing the digital work, the usage right, and the digital ticket in a first repository; requesting by a second repository to the first repository access to the digital work, the request by the second repository including an identification of the usage right; determining by the first repository if the digital ticket for the usage right indicates that the usage right has been exercised the predetermined number of times; if the digital ticket indicates that the usage right has been exercised the predetermined number of times, denying access by the first repository to the digital work; if the digital ticket indicates that the usage right has not been exercised the predetermined number of times, granting by the first repository access to the digital work; and punching the digital ticket to indicate an instance of exercising the usage right.
 3. The method of claim 2, wherein the first repository punches the digital ticket to indicate the instance of exercising the usage right.
 4. The method of claim 2, wherein the second repository punches the digital ticket to indicate the instance of exercising the usage right.
 5. The method of claim 1, wherein the digital ticket includes address information designating a repository for punching the digital ticket.
 6. The method of claim 5, wherein the designated repository comprises a special ticket agent.
 7. The method of claim 1, wherein the usage right specifies a manner of rendering at least a portion of the digital work.
 8. The method of claim 1, wherein the digital ticket comprises an instance of a digital work.
 9. The method of claim 1, further comprising storing the digital ticket in a memory device.
 10. The method of claim 9, wherein the memory device is an ASIC chip.
 11. The method of claim 9, wherein the memory device is a PC card
 12. The method of claim 9, wherein the memory device is removable.
 13. The method of claim 1, wherein the usage right indicates that access to the digital work requires a fee.
 14. The method of claim 1, wherein the digital ticket includes a timestamp part for indicating a time when the digital ticket was punched.
 15. The method of claim 1, wherein the digital ticket includes a timestamp part for indicating a time when the digital ticket was used.
 16. The method of claim 1, further comprising timestamping the digital ticket when the digital ticket is updated.
 17. The method of claim 1, further comprising refreshing the digital ticket to enable subsequent use.
 18. The method of claim 1, wherein the method is implemented for use in a computer system for controlling the distribution of digital works
 19. The method of claim 1, wherein the method is implemented with one or more hardware and/or software components configured to perform the steps of the method.
 20. The method of claim 1, wherein the method is implemented with one or more computer readable instructions embedded on a computer readable medium and configured to cause one or more computer processors to perform the steps of the method.
 21. A computer program product for controlling the number of times that a usage right associated with a digital work can be exercised, including one or more computer readable instructions embedded on a computer readable medium and configured to cause one or more computer processors to perform the steps of: creating a digital work; determining a usage right for the digital work, the usage right specifying a digital ticket, the digital ticket indicating a number of times the usage right may be exercised; requesting access to the digital work including an identification of the usage right; determining the validity of the usage right based on a number of times the digital ticket has been used; granting or denying access to the digital work based on the result of the determining step; and updating the digital ticket if access to the digital work is granted.
 22. The computer program product of claim 21, further configured to cause the one or more computer processors to perform the steps of: creating the digital ticket with an indicator of the predetermined number; storing the digital work, the usage right, and the digital ticket in a first repository; requesting by a second repository to the first repository access to the digital work, the request by the second repository including an identification of the usage right; determining by the first repository if the digital ticket for the usage right indicates that the usage right has been exercised the predetermined number of times; if the digital ticket indicates that the usage right has been exercised the predetermined number of times, denying access by the first repository to the digital work; if the digital ticket indicates that the usage right has not been exercised the predetermined number of times, granting by the first repository access to the digital work; and punching the digital ticket to indicate an instance of exercising the usage right.
 23. The computer program product of claim 22, wherein the first repository punches the digital ticket to indicate the instance of exercising the usage right.
 24. The computer program product of claim 22, wherein the second repository punches the digital ticket to indicate the instance of exercising the usage right.
 25. The computer program product of claim 21, wherein the digital ticket includes address information designating a repository for punching the digital ticket.
 26. The computer program product of claim 25, wherein the designated repository comprises a special ticket agent.
 27. The computer program product of claim 21, wherein the usage right specifies a manner of rendering at least a portion of the digital work.
 28. The computer program product of claim 21, wherein the digital ticket comprises an instance of a digital work.
 29. The computer program product of claim 21, further configured to cause the one or more computer processors to perform the step of storing the digital ticket in a memory device.
 30. The computer program product of claim 29, wherein the memory device is an ASIC chip.
 31. The computer program product of claim 29, wherein the memory device is a PC card
 32. The computer program product of claim 29, wherein the memory device is removable.
 33. The computer program product of claim 21, wherein the usage right indicates that access to the digital work requires a fee.
 34. The computer program product of claim 21, wherein the digital ticket includes a timestamp part for indicating a time when the digital ticket was punched.
 35. The computer program product of claim 21, wherein the digital ticket includes a timestamp part for indicating a time when the digital ticket was used.
 36. The computer program product of claim 21, further configured to cause the one or more computer processors to perform the step of timestamping the digital ticket when the digital ticket is updated.
 37. The computer program product of claim 21, further configured to cause the one or more computer processors to perform the step of refreshing the digital ticket to enable subsequent use.
 38. A system for controlling the number of times that a usage right associated with a digital work can be exercised, the system comprising: means for creating a digital work; means for determining a usage right for the digital work, the usage right specifying a digital ticket, the digital ticket indicating a number of times the usage right may be exercised; means for requesting access to the digital work including an identification of the usage right; means for determining the validity of the usage right based on a number of times the digital ticket has been used; means for granting or denying access to the digital work based on the result of the determining step; and means for updating the digital ticket if access to the digital work is granted.
 39. The system of claim 38, wherein the digital ticket is created with an indicator of the predetermined number, and the system further comprises: a first repository for storing the digital work, the usage right, and the digital ticket; and a second repository for requesting to the first repository access to the digital work, the request by the second repository including an identification of the usage right; wherein the first repository determines if the digital ticket for the usage right indicates that the usage right has been exercised the predetermined number of times, if the digital ticket indicates that the usage right has been exercised the predetermined number of times, the first repository denies access to the digital work, if the digital ticket indicates that the usage right has not been exercised the predetermined number of times, the first repository grants access to the digital work, and the digital ticket is punched to indicate an instance of exercising the usage right.
 40. The system of claim 39, wherein the first repository punches the digital ticket to indicate the instance of exercising the usage right.
 41. The system of claim 39, wherein the second repository punches the digital ticket to indicate the instance of exercising the usage right.
 42. The system of claim 38, wherein the digital ticket includes address information designating a repository for punching the digital ticket.
 43. The system of claim 42, wherein the designated repository comprises a special ticket agent.
 44. The system of claim 38, wherein the usage right specifies a manner of rendering at least a portion of the digital work.
 45. The system of claim 38, wherein the digital ticket comprises an instance of a digital work.
 46. The system of claim 38, further comprising a memory device for storing the digital ticket.
 47. The system of claim 46, wherein the memory device is an ASIC chip.
 48. The system of claim 46, wherein the memory device is a PC card
 49. The system of claim 46, wherein the memory device is removable.
 50. The system of claim 38, wherein the usage right indicates that access to the digital work requires a fee.
 51. The system of claim 38, wherein the digital ticket includes a timestamp part for indicating a time when the digital ticket was punched.
 52. The system of claim 38, wherein the digital ticket includes a timestamp part for indicating a time when the digital ticket was used.
 53. The system of claim 38, further comprising means for timestamping the digital ticket when the digital ticket is updated.
 54. The system of claim 38, further comprising means for refreshing the digital ticket to enable subsequent use.
 55. The system of claim 38, wherein the system is configured for controlling the distribution of digital works
 56. The system of claim 38, wherein the system is implemented with one or more hardware and/or software components. 